I have an older brother who, like many an older brother, liked to tease me. I found it to be a source of frustration as a child, but now look back on our interactions with amusement.
One frequent disagreement between my brother and me was over the television. While I was watching television, my brother would sit on the floor in front of the screen and block my view. My reaction was usually a direct request of, “Can you move?” My mistake! Responding literally, my brother would sway back and forth metronomically, intermittently blocking my view. You can imagine my annoyance! Further, this all occurred before the invention of DVRs, which meant I couldn’t pause the show until the standoff was over.
To get an unobstructed view of the TV, my young mind constructed the solution: “If I can get my brother to move, I can see the screen again.” And, had I made my request in the form of an outcome, I would have yielded the desired result: “Stop blocking my view of the TV!”
I offer this humorous example of fraternal strife because it illustrates (in a small way) the flawed approach organizations sometimes take to technology projects. These issues are manifested in the planning portion of a project and response to change.
There are some common problems to consider when approaching technology projects. Having the proper process goes a long way to addressing issues to which even the best organization can fall prey:
Major projects have some level of change, so it is important to plan for when it will happen, not if it will happen. When I consider change, I think back to a slide presented by one of my professors that graphically addressed the cost of change. The bar chart illustrated what is obvious: that the further a project progresses the more expensive the change will be.
It is much less expensive to address a change in requirements during planning. Every additional step—design, coding, testing and deployment—adds more pre-work and thus more cost. Proper definition of requirements saves time and money. When a potential change is surfaced, it is important for the team to evaluate whether it is needed, if it truly adds value and it demonstrably important.
It is for these reasons (and many more) that the proper approach to a technology project is critical for success. The proper team will have the experience to approach the true end users in a way to help them to articulate the outcome and define success.
There is no one formula for project success, but following some basic tenets will help to create the environment for a successful project that avoids pitfalls and efficiently deals with change.
Gain the Ability for Cloud Agility: Assessing Enterprise Capacity to Embrace a Multi-Cloud Strategy
White Paper, BPI Network
About the Author
As Trilix’s primary technical leader, Randy ensures all engagements and solutions are of the highest quality—working with clients from presales through execution to make certain they have business-outcome improvement based engagements.
He has more than 20 years of experience driving vision and intelligently leveraging solutions in technology, having previously worked as a Client Engagement Partner at Atrion, Director of Development at multiple healthcare software vendors, and IT Director at Lifespan, among other roles. He is a Certified Scrum Master and received his Master of Science, Information Technology, from Carnegie Mellon University (while working full-time and still finding time to spend with his wife and two kids!).
Welcome to BTOES Insights, the content portal for Business Transformation & Operational Excellence opinions, reports & news.
Full-length speaking sessions from the Business Transformation & Operational Excellence World Summit, accompanied by featured articles from the Speakers themselves.