Message to Som Gollakota

Please Enter All Requested Information Below
Your Name
Email Address
Message
Leave this Blank:
Woodinville, WA
Project Management - Handling Scope Changes
April 14, 2009
T
he need for competitive edge in companies today tends to render the business needs "agreed upon" a month ago, quite limiting, if not completely outdated. Gone are those days when business owners threw a bunch of requirements over the wall, and the IT delivered solutions a year later. Today in the age of instant gratification, we are talking about how quickly (within a matter of months, if not weeks) can we deliver solutions to market, add market value, and stay ahead in the highly competitive world. If we don't deliver, our competition will. The fact that the business needs change a few times before the actual delivery, is here to stay. "Requirements are locked. I will not accept any more changes" is no longer acceptable.
A business-savvy technical project manager must know how to handle these changes, not to avoid or minimize scope creep (it will happen), but to deliver goods/services that add business value. After all, if the project cannot add full business value without these changes, would the project really be successful in a business sense? Every time a business customer walks in with a new or changed request or need, we must ask ourselves a few "and" questions - How do I tell my customers that I may not be able to accommodate their request, and keep them satisfied, and deliver business value, and deliver on time and budget? Be diligent and be patient. Be also a little strategic and a little tactful.
  1. Ask questions and listen to the customer; understand the business need and the negative affects (of not fulfilling the need). Usually, all that you hear from a customer is "We cannot deploy if this requirement is not met". Ask why!
  2. Understand why the business owners/customers term the project as a failure if a late-breaking requirement is not met. Ask what other ways, if any, the requirement can be met without adding scope to the project. Ask how they are currently dealing with that requirement. Ask questions to understand the business need rather than understand the technicalities and details of the stated requirement.
  3. Move swiftly to collaborate with the experts on the team to assess and understand the impacts to triple constraint  (scope/schedule/budget). Verify if there are any less invasive, short-term alternatives.
  4. If the impact is negligible, accept the change and schedule it for delivery. Everyone is happy.
  5. If the impact is manageable (thumb rule <10% of the original cost/timeline), it requires a little bit more work to do.
  6. If the impact is significant (thumb rule ≥10% of the original cost/timeline), it requires a lot more work to do.
Keep in mind that these impacts I am talking about are essentially negative impacts - meaning, they make the numbers associated with the project standard constraints higher (such as, increase in scope, costs more, takes more time, requires more resources quality has to be compromised, etc.). If the change is to reduce stuff, then no problem (well, not exactly... we still need to investigate why the reduction has to occur, but...).
Work to do:
  1. Business Owner To-Do List
    1. Articulate and document the new or change request in business terms and language. What is needed and more importantly, why?
    2. Build a business case to document why we need it, positive value of of having it, and negative affect(s) of not having it is.
    3. Quantify the positive business value (Returns) and negative business impacts with numbers as much as possible (hard/soft dollars, percentages etc). Effectively push back on statements such as "It will greatly enhance customer satisfaction", or "It will have a huge impact on our bottom line".
  2. IT Project Manager To-Do List (starts after 1.a is complete) (total duration - <1 week)
    1. Run the new or changed requirement thru various IT groups (Analysts, Developers, Testers, Support Personnel)
    2. Secure a preliminary (very high, t-shirt size level) impact and effort assessment to deliver the request
    3. Estimate costs to deliver based on effort to deliver
    4. Feed this information back to the business owner to ensure the returns are greater than investment
  3. Ensure that the returns are significantly greater than the investment over the life of the end deliverable. Again, work with the senior management on the business side  to agree upon hard numbers to quantify the term "significant"
  4. Work with the senior management on the business as well as the project management side to quantify the term "Significant" in hard numbers (>10% or > 50% etc.). While doing so, also understand what the current numbers are. For example, "Implementing this change will result in greater than 10% returns on the current returns projection of $50 million a year" or "Not implementing this change will result in a scale back of the projected $50 million a year return, by over 10%".
A good way of measuring Significantly Greater Return On Investment is, investment is recovered within less than 25% of the lifespan and returns occur thru the end of the lifecycle. E.g. Investment = $100 K; Return on Investment = $400 K in next 4 years and $50K every year there after.
Remember - this is the homework for scheduling delivery. When it comes to delivery, there are a host of negotiating tools at your disposal. Tools such as incremental (Agile) delivery, next version or a new project altogether, extending current delivery timeline (last-resort option) and so on. If the business case is strong enough and the impact is significant enough, you are looking at one or more of the following - more funds, more resources, next version, delayed delivery and/or new project. Regardless, you have a leadership escalation on your hands. Start Escalation Procedures!
Secret Tip: Chances are, while writing a strong business case, the business owners may realize the requirement may not hold as much water, and may drop it all together. Or the team may realize that they missed a critical requirement and move forward with better value to the business and better chances of success. Even in a worst case scenario, a grave risk to the project success would have been avoided or mitigated.
----------x----------