Productivity-for-PR

You can rescue a failing IT project

If you work in the IT world, you’ve probably seen projects that have come off the rails and require a major course correction to get back on track. In this blog post, I will highlight the warning signs of a failing project from a recent client, along with the process we follow to get critical initiatives back on track.

Danger ahead!

This client was replacing an important legacy system as part of a long-term modernization program. The project had been in danger from the start:

  • High IT team turnover rate led to new hires that didn’t know the business
  • No strong project management on the team
  • Selected this project to initiate an Agile development approach
  • No Product Owner to represent the needs of the business

After two years only one major module had been delivered and the updated project timeline was three times longer than the original schedule. The alarming and unexpected extension of the timeline was the motivation our client needed to contact Edgewater for help.

Project Assessment

Our first step was to conduct an assessment of the project to better understand:

  • Major risks
  • Staffing and capabilities
  • The estimation approach
  • User involvement
  • Agile adoption

In this case, the findings clearly indicated a project at a high risk of failure.

Recommendations

Given the determination of “high risk”, Edgewater recommended some bold changes:

  • Establishing a realistic project schedule with achievable milestones
  • Hiring a full-time Product Owner to lead the requirements effort and build the backlog
  • Doubling the size of the IT development team to increase productivity and reduce the timeline
  • Using a blended team of full-time resources and consultants
  • Adding a full-time Project Manager/Scrum Master to lead the Agile development team, keep the project on schedule, and provide reporting to senior management

Initial results

After the first six months, the results are very promising:Productivity-for-PR

  • The project timeline has been cut in half
  • The development team has increased productivity by over 50% and has delivered modules on schedule
  • The requirements backlog has doubled
  • The client IT team is learning best practices so they will be able to support and enhance the system on their own
  • The Project Manager is mentoring the team on Agile roles and responsibilities, and managing the development team

Our client is extremely happy with the productivity improvements, and the users are excited to work on this project.  There’s still a long way to go, but the project rescue has been a success.

To learn more, watch our video then contact kparks@edgewater.com.

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.

Ten Ways to Ensure Project Failure

Sometime ago I read an article about the top ten ways to destroy the earth. Although it is a bit morbid to even think about such a topic let alone compile a top ten list, it certainly is an interesting scientific problem. Blowplanet_collide0ing planet earth to bits is not as simple as it may seem. It takes considerable amount of energy to blow up six sextillion tons of rock and metal. However, there are some exotic ways to get the job done. From creating a micro black-hole on the surface of the earth to creating an anti-matter bomb with 2.5 trillion tons of anti-matter to creating perfect Von Neumann machines (self-replicating), they are all pretty futuristic and not part of our everyday experience. Some may say- “why even think about such an absurd subject?”, but it does have few practical applications. If nothing else, it helps us think about possible dangers to the only known planet capable of supporting life.

While blowing up earth may for now be out of our grasp and may require giant leaps in technology, blowing up an IT project is quite easy. I can say that with authority, because I have seen many projects self-destruct right in front of my eyes and at times I may have contributed to some of them. So here are the ten ways of blowing up an IT project:

  1. The Missing Matter—Requirements: Lack of business and functional requirements or requirements lacking appropriate level of detail.
  2. Progress Black Hole: Lack of mechanisms to measure progress, milestones, and deadlines.
  3. Caught in the Gravitational Pull of Technology: Focus on technology itself rather than achieving business objectives through technology.
  4. Supernova – Out of Resources: Unrealistic expectations and deadlines – trying to achieve too much in too little time and with too few resources.success_failure1
  5. Consumed by Nebulous Clouds: Constantly changing requirements and feature creep. Inability to give the project and product a solid shape and direction. Lack of proper change control process.
  6. Bombarded by Asteroids: Loss of focus and progress due to multi-tasking on unnecessary side projects and other distractions.
  7. Lost in Space: Lack of a well defined project plan with appropriate level of details, milestones, and resource allocations.
  8. Too many WIMPS (Weakly Interacting Massive Particles): Lack of interaction with the business users, lack of sufficient number of check points, lack of business user involvement during the planning, build, and deployment phases.
  9. Journey to the Edge of the Universe: Attempting to run a project with bleeding edge technology, inexperienced project team, and poorly understood business objectives.
  10. Starless Solar System: Lack of clear and convincing business case and mapping of how the project will help to achieve the business objectives.

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.