Reboot the PMO

With organizations like the Project Management Institute, there’s no shortage of substantive resources in the marketplace today that can help IT projects succeed by offering PMO best practices, training, and accreditation. But all the training and certificates in the world can’t push a project across the finish line if it has the wrong organizational champions. That’s why I’m proposing a reboot of the PMO. In my experience, there are three important factors that determine whether a project succeeds or fails.

  1. Obtain buy-in: Frequently, a project is doomed from the start because the right stakeholders do not support the project or its goals. Executive stakeholders must be completely aligned on a project’s priorities and strategic direction and be totally committed to implementing the necessary organizational and cultural changes. Stakeholders also must provide a clear vision and ensure that everyone can understand and believe in the story.
  2. Conduct self-reflection: PMOs spend most of their time overseeing the work of others, so it’s not surprising that they frequently overlook the importance of self-reflection when it comes to their own roles. To successfully oversee projects, PMOs must also be aligned with the strategic direction of the organization and committed to their role in its victory. They also must provide better visibility with ongoing projects, remain flexible, and collaborate with managers on the ground to determine what’s working and what is not. These iterative feedback loops between the PMO and those in the trenches ultimately result in better overall processes for the organization. PMO leaders also must be able to reinforce and articulate the vision for a project’s success.
  3. Consider intangibles: PMOs are not about process for the sake of process or injecting whizbang technology as a way to justify budgets. Perhaps more than anything else, PMOs are about fostering the right talent and culture within an organization so that successful projects are a routine byproduct of the process. To do so, PMO leaders must influence the right behaviors and remove impediments to success. This allows a project team to adjust and make changes when they need to and encourages all team members to participate. Once everyone is on the same page, these behaviors become woven into the fabric of the organization.

When teams take ownership of outcomes, they will always do what it takes to ensure a project succeeds. With this combination of attitude and culture, the entire organization—and the customer—wins.

How Should We Assess Risk For Our Projects?

Firstly, we need to consider that doing risk assessment is our attempt as project managers to minimize the possibility of failure. We define failure as one of three things:

  • Exceeding the time allocated to complete the project
  • Spending more than the budget allocated for the project
  • Not meeting our client’s requirements

Secondly, we can generalize that projects fail for two reasons:

  • External events negatively impact the project – such as having insufficient resources, uncontrolled scope changes, and unanticipated events
  • An overly optimistic plan requires the team to hit pre-set targets – sometimes due to having these targets dictated by others without sufficient insight into what it takes to get the project done, and at other times due to failure to properly scope the project, or blithely expecting that all targets will be met in a timely way and technical problems will be minimal – in the name of being a good team player.

We would maintain that part of planning for risks consists not only of expressing time and budget estimates as ranges at the beginning of the project (which allows for the actual risks that may occur) but using those ranges and estimates to establish contingency percentages for the project (most effectively done for the project as a whole rather than at the task level). However, although contingency planning is necessary, it is not sufficient. The part that is often left out is that a full risk assessment should be done once the project team has been fully assembled and has started to work on the project – around the 20% completion mark.

Performing an assessment at this point allows the team to determine how realistic the original risk assessments were and also to add to (or subtract from) the list of possible project risks. Any assessment of this type needs to involve the key members of the team (Project/program manager, Lead Business Analyst, Lead Technical Architect, Business sponsor, senior program and QA leads, etc.) to get a true picture of all the risks impinging on the project. This type of assessment should be done one-on-one with each individual for larger programs/projects and/or using a survey instrument for smaller projects and needs to include both a quantitative assessment (What level of risk, on a numeric scale, does a particular risk represent to the project and/or to the business as well as the probability, on a numeric scale, of the risk actually coming to pass) AND in addition, a qualitative assessment.

Many organizations often ignore or downplay the need for the qualitative assessment. However, as has been proven many times with techniques like Six Sigma, your staff is usually very aware of the issues that are occurring or likely to occur, and can pinpoint them and suggest possible solutions. Our experience in doing this type of assessment for companies has shown that this type of risk assessment is best led by individuals not involved in the project being considered to avoid conflicts of interest in reporting what is actually happening within the project.

Performing this type of assessment and covering both the quantitative and qualitative issues will insure a higher likelihood of risk assessment accuracy and result in more successful projects over time.

Scrum Fills the Leak in the Waterfall Methodology (Part 2)

Read ‘Part 1’ Here.

Although there are many reasons for Waterfall Failure or Waterfall ‘Leaks’, here are some common causes:

Requirements & Scope Control

Requirements tend to be unclear, lack agreement, lack priority, can be contradictory, ambiguous, and imprecise. With that said, Waterfall assumes a detailed set of requirements will be 100% accurate at the beginning and locked for the duration of the project. Changes to requirements are bad and Waterfall tries to minimize once the plan is created.

Planning (schedules & budgets)

Schedules and budgets can be based on insufficient data, missing items, insufficient details, and poor estimates. Waterfall assumes the initial estimates are locked and accurate. Frequently dates and budget are decided well before even project engineers had a chance to provide their own input on estimates.   These same team members are then forced into long spanning timelines they don’t agree with. This can also lead to overly cautious PMs who end up in ‘analysis paralyses’ during the planning phase in an attempt to perfect estimates which can delay the start of the project.

Communication

Another common reason for failure is poor communication and stakeholder engagement. This also causes lack of clarity and trust. Waterfall assumes the PM should plan all the work or tasks (i.e. planning from the center) and the project team must execute the tasks they are assigned. There is no sense of ownership from the team’s perspective.

Customer Value (and quality):

Typically, Waterfall does not provide any value back to the customer until the very end after all other phases. All requirements are locked together as they journey through all the waterfall phases only to realize that what they wanted a year ago is already obsolete and needs changing. Waiting to do the testing until the end of the project risks finding out a major issue right before deployment which will cause the project dates to slide and be over budget. A common waterfall solution to this is to reduce testing effort to ‘keep the dates’ and turn over a poor quality system into production. Read more

Scrum Fills the Leak in the Waterfall Methodology (Part 1)

Although the Agile Methodology has been around for more than ten years, Scrum is still relatively new to most people in the project management field – although it is gaining ground. Scrum is the leading agile development methodology, used by Fortune 500 companies around the world. Not only does it change the mechanics of traditional project management (i.e. waterfall), it’s also a philosophical change for the team that uses it. This article will not go into details on how scrum works, but how the benefits of Scrum fix waterfall shortcomings.

The methodology that has dominated software development projects for decades is called “waterfall.” Winston Royce coined the term in his 1970 IEEE paper “Managing the Development of Large Software Systems” to describe a serial method for managing software projects through the development stages (Requirements, Analysis, Design, Code, Test).   However, Royce himself acknowledges the issues with this process: “I believe in this concept, but the implementation described above is risky and invites failure.” He goes on to actually promote iterative development but that seems to have been ignored (or a less understood concept).

After 40+ years, why doesn’t waterfall work? The articles and statistics are endless…

Studies have shown that in over 75% of the investigated and failed software projects, the usage of the Waterfall methodology was one of the key factors of failure.

A study by McKinsey & Company in conjunction with the University of Oxford of 5,400 IT projects found 17 percent of the large IT projects go so badly that they can threaten the very existence of the company. On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted.

A more recent study by Innotas reports that 50 percent of companies had an IT project fail in the last 12 months.

Read ‘Part 2’ Here.