One of my favorite sayings is that bad news does not improve with age. This also holds true with identifying scope changes. I'm certain everyone has come across a scope change or two in your time. One truth of business is that scope change will occur. Another scarier concept is that your sponsor may not understand the costs of performing a scope change during analysis versus after unit testing. One of our responsibilities as good project managers is to make certain, the project team, sponsor, and stakeholders all understand the relative costs in identifying and performing scope changes sooner in the lifecycle rather than later. Hopefully, this will help why it is well work the planning time to firm up the discovery, analysis and detailed requirements and portray the value of a good scope understanding by all during planning.
Further Readings
Subscribe and Share!
Did you enjoy this article? Your feedback is very important! I'd like to invite you to keep up to date with the latest posts from Anticlue. We offer several venues. If you have some questions, help can be found here.- Become a Facebook Fan
- Subscribe to Anticlue
- Follow me on Twitter
- Add to Technorati Favorites
- Digg this post
3 Comments to “Relative Costs of performing a scope change sooner rather than later”
One thing which can really mitigate the affect of scope change is taking a less traditional IT approach to working with your clients.
The old adage, code speaks louder than words always holds true. The above pyramid will nearly always induce scope change, it's too inflexible.
Use a phased approach and budget for some change. Review the next phase in light of the things learnt in the previous phase.
Often the scope creep can drastically reduce ongoing costs for the life of a project. Just fixing the problem once and for all, is often better than documenting the workaround
Clients often need to see it and try it in order to understand what they are actually after, before they can provide the feedback you really need to achieve a good solution.
Hi Zac,
Thanks for commenting, your statements are very true for a development environment using another methodology such as agile. However, for our purposes here in Healthcare IT, we rarely develop build solutions. Mostly, we buy and customize. The customization is based upon the vendor's toolsets. Most organizations using these toolset still use the waterfall methodology upon which this graph is based.
It would be interesting to see hear if anyone in Healthcare IT is using vendor toolsets with a Agile methodology!
Hi there, I create your blog via Google while searching throughout earliest grant-in-aid since a marrow engage in struggle and your post looks definitely intriguing after me
Please share your thoughts and suggestions
-
Receive Our eNewsletter
The latest Project Management and Healthcare IT practices
-
About Me
Welcome to the Healthcare IT Project Management Blog of Elyse Nielsen. This is the place where I share the ideas I have learned, the things I’d like to remember, and my thoughts for a brighter future. Find out more.
Subscribe to Our Tips
This weblog is licensed under a Creative Commons License.