Project Triage During Rapid Business Change Cycles

A few years ago, we ran a series of blog posts on project triage, diagnosis and rescue:

How often do you perform project triage?triage

Preparing for Project Rescue: Diagnosis

Restoring Projects to Peak Performance

In much of our work since then, we have been working with organizations that struggle with performing meaningful project interventions to align their project portfolio with sudden shifts in business strategy, or to support their underlying corporate culture as it shifts toward more rapid innovation, originality, adaptability, engagement, collaboration and efficacy.

In such fluid business environments, our original medical metaphor doesn’t fully apply; triage and diagnosis were performed from a perspective of project internals.  In today’s world, the old project success indicators can be very much out of sync with the business.  If IT projects, the project portfolio, and a PMO are not accountable in terms of their value to the business, it’s time to change the ways we think and talk about projects, and begin to define new KPI’s for success.

  • First of all, let’s stop using the term scope creep.  To deliver business value, the project organization must be agile enough to rapidly address scope fluidity. Would it make more sense to measure how quickly a project team can replan/re-estimate a shift in scope?
  • Quality metrics may also need to fall by the wayside. Is the current release good enough to push into production with defects noted, and expectations managed–think of the release as a minimum viable product, like lean startups do?
  • In rapidly changing businesses, it’s very difficult to plan out a 12 month milestone plan for IT projects. It makes more sense to define a backlog of objectives at the beginning of the planning phase, and perform rolling prioritization, with the complete expectation that the prioritization will change at multiple points during the coming year. In such an environment, how meaningful is it to judge project success against the old notion of “on time”?

In the context of all of this change, it is no longer reasonable to judge projects based on their internal conditions. The measures of project success in today’s world lie in the greater business context.

  • Has the project or project portfolio enabled the business to respond to threats and opportunities more rapidly?
  • Has it increased our innovation speed?
  • Even if the application is buggy, has it improved overall efficiency, enhanced the quality of goods and services, reduced operating costs, or improved the business’ relationship to its customers?

While these questions have answers that are less quantifiable, they are certainly more meaningful in today’s business context. How is your business evaluating project success these days?

2010 New Year’s Resolutions: Project Management/PMO

Along with the holiday festivities, the last half of December turns everyone’s thoughts to New Year’s Resolutions. If you adopted any of our project management resolution suggestions from last year, please leave a comment and let us know how that worked out for you. And, if you haven’t taken our survey about project success, please do. It will take you only 5 minutes, and we’re looking for both IT and business perspectives.

For 2010, we’re expanding the scope of our resolutions to include a few PMO resolutions as well. (Don’t worry, we’ve filed a change control request and had it approved by the proper authorities!) We approached 2009’s resolutions with an eye toward cost reduction, based on a grim IT budget outlook. 2010 looks like it will not see further cuts, with most companies either keeping budgets in line with prior year, or boosting IT spending by a modest 4-6%.

In this budget context, it’s still wise to consider ways to work smarter, not harder, and tighten up the alignment of all of your projects with the overall strategy of the business, realizing that the strategy often changes over time.

So, without further ado, here are our 2010 Project Management/PMO resolutions:

1. Writing up your meeting minutes is not as critical as limiting the minutes your team spends in meetings. Don’t get me wrong: published meeting notes are important, and they should still be distributed within 24 hours of each working meeting.  The following mental exercise will bring home the importance of running tight, efficient meetings:

1. Count the number of meeting attendees.

2. Multiply by the length of the meeting in hours.

3. Multiply by the number of meeting occurrences over the project lifespan.

4. Multiply by a fully burdened hourly rate.

A weekly internal status meeting for a year-long project could be adding significant cost to your project. Limit your agenda to the essentials: It’s not so important to review what everyone has done or what went well. Use the meeting time for resolving issues and managing exceptions.

2. Revisit the charter for your PMO and make sure it serves the business, and does not ask the business to serve the PMO. PMOs that exist to enforce consistency and police compliance with a methodology often end up slowing down project execution instead of enabling project success. Standardize project plan templates at the highest level necessary for tracking milestones across projects, and let individual project managers develop work breakdown structures within that framework, to a level that suits the needs of individual projects.

3. Develop a less adversarial attitude toward change. Much is written about scope creep and change control in project management circles. There may be a tendency to take too hard a line toward change. The reality is that business conditions, needs, and strategy may well change over the lifespan of many projects.

Let’s move our definition of project success away from the old metrics of “on time and within budget” toward more realistic measures of business success. Some more appropriate ways to judge success of a project include:

  • Did the project fulfill the objectives, as defined in the original project charter (if you don’t do project charters or business cases, add that to thei list of resolutions) and all subsequent change requests?
  • Are end-users satisfied that their requirements have been implemented, and can they easily perform their daily tasks using the new system?
  • Some metrics are specific to the type of project, such as:
    • For business intelligence projects: Has this project enabled the business to make better and quicker business decisions by putting better data and drilldown capability into their hands?
    • For projects that install new transactional systems: Have we improved overall efficiency and accuracy of critical business transactions?

4. Develop an efficient framework for project triage. Not every project needs the same level of support. Some projects need to be suspended or rescoped as business needs change. Regular project triage is a best practice that helps organizations make sure they are keeping IT budgets aligned with business needs. Make a commitment to quarterly triage in 2010. Incidentally, if you haven’t taken our project triage survey, we would value your input in this area.

5. Re-order the priorities of your project managers. Make sure that they understand that their most important responsibility is maintaining a healthy working relationship with the business. Tracking status, updating the plan, and managing the tech team are not the key enablers of project success.  The most valuable skills to strengthen in your PM staff  are related to communication, conflict resolution, consensus building, and salesmanship (they will often have to “sell” reluctant stakeholders on compromise solutions).

New Year’s resolutions are really just an attempt to institutionalize a project management best practice that should become standard operating procedure throughout the year: periodically re-examine your approach and commit to continuous improvement efforts. That’s the real secret to successfully building a high-performance project management office within your organization.

Restoring Projects to Peak Performance

You’ve performed project triage.
You’ve run the required diagnostic tests.
It takes more than a diagnosis to avoid more implementation failures.  Now what?

Here are some quick remedies and prescriptions for fixing ailing projects:

Treatments for project illnesses
Treatments

This takes us back to the beginning of the cycle. Periodic triage and interim project health-checks are the best way to make sure your project portfolio will contain fewer implementation failures.

Preparing for Project Rescue: Diagnosis

In my last project management blog post, I talked about performing triage on a project portfolio.  Over at the Oracle Infogram blog, they picked up on our post with a reminder that triage is a pervasive activity, and one that is essential to project management:

“Triage runs from the queuing on the CPU all the way up to the user’s daily calendar entries, it is a concept that should always be kept in mind when planning and building projects.”

The result of the triage effort is to identify those projects most in need of immediate intervention.  Just as in the medical world, the next step after triage is diagnosis; now it’s time to focus on projects in the third group and perform project diagnostics. If you are tasked with rescuing a failing project, here are the first steps that you should take to find the root cause(s) of the project’s difficulties.

patient history1. Obtain a thorough patient history: Skilled medical diagnosticians may not rely solely on the patient’s recollection. In some cases they need to interview family and friends to obtain information on subtle symptoms.  Likewise, the skilled project diagnostician should combine the skills of Dr. Gregory House and Dr. Cal Lightman.  When trying to diagnose failing projects, they shouldn’t don’t rely solely on direct interviews of the project team. A multi-perspective view of the situation is needed:

  • Have a closed-door session with the project sponsor: Find out what the key issues are with the project and begin to explore areas where a rescoping might help bring things back on track. Find out what kind of scope reductions are likely to be accepted by the business, and which might require significant salesmanship or a fierce battle. Understand the organization’s politics so that you can factor them into your corrective action plan.
  • Talk to the project stakeholders about their original expectations, their current concerns, and any difficulties they may be experiencing with the project team.
  • Create comfortable communication channels with all members of the project team, and dig deeper than project plans, status reports and issues logs. Find out what is causing project anxiety within the team.  There are often valuable clues here. Be sure to probe any areas that are glossed over or brushed aside quickly.

 2. Next, take the project’s vital signs:

  • Pulse check: Assess the burn rate. Are you eating up budget faster than you anticipated? What is the new estimated total cost?
  • Blood pressure: perform a risk assessment, in terms of what could happen between now and the go live date to cause a significant incident. Various frameworks exist for this assessment. The Six Sigma FMEA template can be modified to suit your needs here, giving you an objective framework for assessing all possible places where your solution could fail, and steering your future corrective actions toward those that have both the highest likelihood of occurrence and greatest criticality.
  • Temperature:  Red yellow green heat sheet with respect to key milestones. This should be part of your regular status report, along with some basic trending. For example, we once managed a huge portfolio of interdependent concurrent projects with weekly reviews that tracked both last week’s and the current week’s milestone status. Because we were in an M&A situation facing TSA deadlines, we had not time to bring up robust project portfolio management tools, so we kept things moving with simple, homegrown Excel tracking tools.
  • Other specialized diagnostic tests as needed—assess the scope (original and current), review the technology strategy, development strategy, testing strategy, release strategy and change management strategies.

After performing these steps, you should have insight into why the project has gotten off track. Our next blog post will cover some of the intervention steps to take after the diagnosis is complete.

How often do you perform project triage?

A quick google search shows that the medical concept of triage is commonly applied to evaluating IT projects and other major business initiatives. pm_thumbnail

The concept of triage comes from medicine, and in particular medical treatment under difficult circumstances—war, epidemic, disaster—where the number of people needing treatment exceeds the resources available. In such situations, the sick or injured are typically assigned to one of three groups.

 In the business context, it usually means allocating scarce cash and human capital under difficult economic conditions, when the number of ongoing projects exceeds the level available resources.

Project Triage Framework

In the current economic climate, it probably makes sense to perform a mini-triage of your project portfolio quarterly, with an annual triage as the last fiscal quarter approaches.  In addition, you may be faced with the need to triage in emergency situations such as a sudden shift in business strategy, in the face of a new acquisition, or when presented with an across the board budget cut. Periodic review is a cornerstone of an effective project portfolio management strategy. This regular triage can be a valuable form of project insurance. Preventative medicine is always less costly than crisis treatment.

Your triage team should include your senior IT management as well as functional business leadership. Performing project triage is easiest if there is regular, reliable status reporting from the project teams, on their milestone and budget status.

Triage is also easier if your project initiation process includes a business case that assigns a business criticality score to the project. It’s entirely possible that business criticality of a given project might change over the course of the project’s lifecycle, and a master project status tracking document helps the triage team keep track of this.

After reviewing the health of individual projects and their alignment with current business needs, triage will place them into three groups which align perfectly with the medical definition of triage:

1. Persons who are likely to live even if they don’t receive immediate treatment—projects going well that need no additional intervention

2. Persons who are likely to die even if they do receive immediate treatment– projects that you should suspend NOW before they chew up additional resources

3. Persons who are like to live only if they receive immediate treatment– projects that need you to perform an immediate intervention

Our next blog post will cover specific diagnostic tests you must perform on projects that fall into the third group. In the meantime, let us know your apporach to project triage by answering this poll:

How often do you perform project triage?