Project Practitioners > Managing Complex Project Changes

Managing Complex Project Changes

By Matt Glei

I am new to ProjectConnections.com blogging.  I am Managing Partner of Know-how Consulting in Honolulu, Hawaii.  I provide performance coaching in areas such as collaboration, knowledge management, intellectual property, virtual teams, as well as program, project and risk management.  I also have long experience in product development, managing project portfolios and strategic planning.  I thank you for your comments and observations.  Matt Glei

I have found that one of the hardest things to do well in most organizations, large or small,  is to manage changes caused by numerous (and multiple), real world factors:

  • Staffing gaps (takes longer to ramp up or you lose a resource)
  • Feature creep (no, not the marketing person: addition of new / more complex features)
  • Technical difficulty (you discover it’s a lot harder than you imagined)
  • Financial gaps (slow approval of resources, equipment, materials, etc.)
  • Planning gaps (discovering major previously-unplanned work)

Some businesses have formalized ways of managing some of these items, such as change orders in the construction business, but many of these change types do not respond to change orders.

Let’s think about practical ways to manage each of these types of change:

1.      Staffing gaps:  project managers spend untold hours planning project tasks in excruciating detail, but seldom have a clearly-enunciated staffing plan and how they intend to execute to it.  In addition, they need the management team to agree with the staffing plan and help to support it and execute it.  In terms of losing people, the PM should do a risk analysis and work to avoid losing key talent and consider what they will do if losses occur.  Do you have specific examples or methods that you’ve seen work to avoid staffing gaps?


2.      Feature creep:  this area has seen a lot of focus because it can derail an otherwise in-control project.  The construction industry uses formal change orders to help document and control these changes and the client pays for the changes.  Most other industries don’t seem to use that technique.  In product development, having a solid product requirements or specifications document can help, because changes must become visible in that document to get accomplished.  Do companies hold themselves accountable and understand the costs undertaken as product requirements “creep?”  How does a company build accountability and discipline into the process?  This is not only the marketing product manager’s problem -- many are caused by the engineers themselves!  Do you have specific examples or methods that you’ve seen work to avoid feature creep?


3.      Technical difficulty: if this is a high-rise construction project, the process is likely well-understood because many building are built every year – companies have built detailed processes around how to ensure things are done in proper order and on schedule (at least as far as can be predicted).  In many other disciplines, if this is the 15th EKG monitor that a company has developed over the years, the technical difficulties can be estimated with relatively high certainty.  If this is the first lithotripter device ever developed, the technical risks are much more difficult to estimate.  Both types of projects have technical risks – the interesting thing is that the more risky project often gets a thorough technical risk analysis because it is more unknown.  The odd thing is that the more familiar project often gets little, if any, formal risk analysis.  Sometimes the risk is not in the design per se, but in the experience of the team assigned to do it.  Project managers often assume the perfect team, even when the team is not yet known, or assumes that the team members will walk on water (or never take a vacation, get sick, etc.)  Do you have specific examples or methods that you’ve seen successfully assess technical difficulty?

4.      Financial gaps:  this area is similar to staffing gaps, in that there is always a budget established.  However, does the project manager and management review the spending actual vs. plan and worry when spending is below plan?  In my experience, capital and other large planned expenses still have to go through an approval process (even if already approved in the budget and project plan).  This usually means delays in executing to the plan.  Who is accountable for these delays?  The person delaying the approval or the project manager?  Do you have specific examples or methods that you’ve seen successfully avoid financial gaps / delays?

5.      Planning gaps:  Project managers don’t like to talk about this because, if planning gaps exist, it’s our failure, by definition.  Project managers work hard to do a thorough job, but how do you know what you don’t know?  Some gaps are based on bad assumptions, wishful thinking or pressure from management (it’s gotta be done by X or we’re all gonna die!”  The best method I’ve observed is getting a team of experienced people (including marketing) in the room and assess the planning risk of each part – then dig in on the parts that are hard to defend.  In a mature company I’ve actually had a General Manager challenge me to defend how I could do the project as fast as I predicted.  This was the same guy who two years before had wanted to cut my schedules in half!  The difference was that we had instituted the method just described and we made major progress in meeting our schedules, in spite of change.  The goal was “most likely, given reality” rather than “best possible schedule.”  Do you have specific examples or methods that you’ve seen successfully minimize planning gaps?

Now that I’ve blathered on for a bit, let me ask each of you to respond with other examples of change or methods you’ve used or observed to manage the changes described above.  Over the next few days and weeks we can discuss detailed examples and best practices.

Matt Glei, www.KnowhowConsulting.biz



Related Links
A well written product requirements specification document can make it much easier to manage your projects' scope and staffing (not to mention keeping an eye on those ever-popular change requests). Warren Craycroft detailed the disastrous results of a medical device project that knew exactly what they required but forgot to watch where they were going.


Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

Staffing gaps - one way to make this less risky is to treat the staffing plan like any other milestone-based plan. This means a mini-plan around each hire, including creating the job description, advertising, deciding on the interviewing team, etc. Progress on each hire should have visibility just like any other key deliverable. Painful as this may seem, one of the main reasons I've seen for project slips is NOT executing to the staffing plan. It's often "in the budget", but not treated as a part of the project execution.


Feature creep - there are many methods to try to control this. One of the first is to talk to the team, including the marketing product manager and discuss the potential impact of even little additions. The other one that comes to mind is to "enforce" the product requirements document [PRD] or specification. If someone recommends a change to the functionality, you could require that the PRD be modified and approved before implementation of the change. This approval could be formal or not, but should include the Product Manager and the Project Manager, at least. Of course, as part of this approval, there should be discussion of the impact on product design and schedule as well as any other kind of risk. Using a requirements tracing tool can also make this more visible, especially in a complex product.


Technical difficulty - the best way I've observed to do an assessment of the technical difficulty is to convene a review team made up not only of the key architect and design leads, but also an "outside" (the project) experienced senior designer. They need to spend many hours evaluating the parts of the development from the following points of view:

* have the requirements been evaluated with the customer / use base (is this what they want)?
* how well are the architecture and product requirements understood and documented?
* are the people in place to do the specific design component?
* have they done this type or complexity of design before?
* what are the design risks with each component?
* how will these specific risks be mitigated or evaluated?
* how easy is it to test the specific component to determine completeness and quality?
* what are the regulatory or compliance requirements? (FDA, UL, CSA, IEC, ISO, etc.)

Although the tendency is to rush this step, taking adequate time at this stage allows the project manager and management team to add resources or execute contingencies to head off trouble before it happens.

The goal is not to come up with the fastest possible schedule (although it is nice to know this), but to come up with the most-likely schedule, taking into account the risks and mitigations from the review. It is not particularly helpful to evaluate the worst possible scenario schedule, because it assumes failure at every step. Another thing to evaluate past performance on similar-risk projects. At HP, projects were measured carefully, and if the experience was that medium risk projects were 10% late even with careful analysis, then this factor was often taken into account for people planning and internal disclosure purposes. The project team still focused on the most-likely schedule and looked for wins when and where they could, because the wins help offset the losses.

I'm sure there are many other methods to assess technical difficulty...


Financial gaps - this is similar to staffing gaps in some ways. In some cases, the project plan includes significant cost items like NRE (non-recurring engineering) costs, tooling, equipment, etc., but it may not be reflected in the yearly budget. Even if it was reflected or can be covered, many companies have financial approval processes that can take significant time. As discussed in staffing, the best way to not have timing become an issue is to have a mini plan for the key financial items. This includes taking into account not only when the team needs them in place, but also aquisition lead time, allowance for the financial approval process, etc. If one of the metrics for the project is monies spent vs. plan, then this lagging indicator is useful but too late. Estimates for hitting the milestones is a better (leading) indicator. Another key ingredient might be having a specific agreement with the people in the financial chain to make sure that approvals will be done in a timely manner. They need to take responsibility for their impact on your schedule, and you (the project manager) need to make sure you provide the paperwork, justification and so forth in a timely manner. I'm sure there are many other useful techniques and experiences out there ...


Planning gaps - there is some overlap with technical difficulty, but this item is focused not just on the technical aspects. If you have already done a solid evaluation of technical difficulty this is easier. However, there are still non-technical risks to be evaluated. For example, have you taken into account how field beta testing or clinical testing will be accomplished and how you will incorporate feedback or fix problems discovered? Have you taken into account how
user, field and sales documentation and training will be accomplished? Have you established the time required to get the design transferred into manufacturing? Are localization plans fully fleshed out? Are there regulatory submissions that have significant time risk? The list can go on, but without a serious look, the risks that go uncovered are still risks to the project. I'm sure you have other examples and methods that can help the project manager evaluate planning gaps.


I have a favorite technique on "feature creep". I've seen the technique Matt mentions above, 'controlling changes to the PRD, setting expectation that no changes to that doc unless approved through some cycle. But I've worked in places that don't keep PRDs updated once the project is underway, so it would be a doubly hard change to get people to manage it that way.... New features come up and get folded in pronto.

In such situations I've controlled at the "charter" or Project Vision level. It works best as a cultural thing. The team creates the shorter 2 page-ish document early in the project. This is what we're doing and why (business reason). Here are the major parameters - scope (major functionality, features), schedule, budget- we've agreed to. If ANYTHING that affects one of these parameters comes up, gets suggested to ANYONE on the team, it should be made visible immediately. Every team member understands it's their responsibilitly to guard against capricious changes. Having people guard the doors using an easy to process 2 page list of stuff, rather than pages and pages of detailed specs, feels easier I think... I've seen the quietest person on the team be the one to raise their hands and say "now, wait a minute, that would impact the Vision, we need a review of this request." NOTE - I'm not saying DON'T control changes against a more detailed PRD. I'm just saying that controlling againts the higher level statement of the project's reason for being, and major parameters, can be a great tool.


I agree Cinda. If it doesn't affect scope, schedule and budget it can be managed in othe ways than the PRD. The key is to manage it somehow. In businesses that MUST control the PRD, such as medical devices, the PRD is the place to help manage it.


The comments to this entry are closed.




©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy



Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds


Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.