Some Project Management Offices (PMOs) never get off the ground. I've seen others that are started and a year or so later die a slow painful death. So, how can you build a PMO you can be proud of, one that thrives?
No one intends to build an impotent PMO, but it happens. The PMO lacks power and effectiveness. Therefore, people see the PMO as a hindrance, not an enabler.
Let's look at five ways we can improve vitality and provide value to our organization.
"There is only one way to avoid criticism: do nothing, say nothing, and be nothing." –Aristotle
1. PMO Sponsorship. Without a strong, influential sponsor, the PMO is doomed. Don’t have a sponsor? Then don’t create a PMO. Because you will be fighting an uphill battle, one that you will likely lose.
2. Clarity. Define specific, measurable goals. How will you measure the success of the PMO? What are the Key Performance Indicators?
The PMO leader should also be clear about the type of PMO being implemented. The Project Management Body of Knowledge (PMBOK) describes three types of PMOs:
Since clarity is essential to success, you must continuously cast the vision of where you are going, how you get there, and why you are going there.
3. Alignment. Define a process to ensure projects align with the organization’s mission and goals. What criteria will be used to select projects?
For example, the project selection criterion might include:
Kill non-value added projects. Transfer resources to value-added projects. Certainly, resource management across the project portfolio is a critical success factor.
Some organizations also use a gate review process. At certain stages of each project, the project is reviewed to ensure continuous alignment.
4. Execution. Teach project managers to use a scalable project management framework or methodology. Provide templates to aid project managers in their execution. Another tip, offer to mentor and support project managers during the execution of their projects.
5. Continuous Improvement. Evaluate the framework, tools, techniques, templates, as well as the projects. Develop and maintain lessons learned.
Thinking about starting a PMO? I recommend that you develop a project charter with your project sponsor and key stakeholders. Define the problems you wish to overcome, goals, deliverables, assumptions, constraints, and top risks to a successful implementation. You can build a PMO that you are proud of through early collaboration with your stakeholders, persistent leadership, and staying focused on delivering value to your organization. Best wishes!
Fixed date projects occur often these days. The project sponsor picks a date and hands you the project. So, what's a project manager to do? How can we manage fixed date projects?
First of all, don’t freak out. Some things are unrealistic, but others are not. Be positive and ask for some time to do some analysis. Let your sponsor know that you will come back in a week or two with the results.
Second, seek to understand why. Why is the deadline so critical? Be careful in how you ask this. You’re not challenging the sponsor. Rather, you simply want to see things from the perspective of the sponsor. Listen carefully.
Third, start defining the scope. What are the deliverables and the priorities of each deliverable? Can some of the deliverables be implemented later?
Fourth, engage your stakeholders early. Ask them to help you with the analysis. Seek their expertise.
So, what do you share with your sponsor when your analysis is complete? Think of the situation like a puzzle. Consequently, you may offer different options.
So, what do you say to a project sponsor when you've completed the analysis and you know that the deadline is unrealistic? Tell them the truth. Explain the process you went through, who was involved, the constraints, and the results.
When challenged with a fixed date project, think of it as an opportunity. Often times, you can deliver the project on time with the right approach. Here are some things to consider:
Keep in mind - good risk management often shortens the project. Risks are eliminated or decreased. However, there are always residual risks that should be recognized in your contingency reserve. For example, you may specify that the project requires an additional six weeks to accommodate risks on the project.
Your approach to a fixed date project will determine your success. The project manager must have the right attitude, ensure appropriate commitments by the sponsor and the team, and select the right processes, tools, and techniques.
You've heard the war stories of companies that tried to implement commercial software solutions or build new systems. Maybe you've even participated in one or two? Many of these endeavors took longer and cost more than expected. Others were outright failures, adversely impacting the company's bottom line. Let's look at 3 reasons that IT software projects may be challenged or fail.
The Standish Group conducts an annual survey to see why some IT software projects are successful and others fail. Year in and year out, the survey shows approximately one-third of the projects are successful: come in on schedule, on budget, and delivers what was promised. Most projects miss the mark—they are completed late or over budget or lack quality, or some combination of these attributes.
But, it doesn't have to be that way. We can be successful! It starts with understanding the most common causes of software project problems.
Imagine a software project where the project team delivers the project on time and under budget. But the software does NOT meet the users' needs. Why does this happen?
Project teams have their pants on fire! Everyone wants the software yesterday.
So, how do most project teams respond? They skip the critical step of collaborating with the users. These teams make assumptions about the user needs without even asking.
Oh, you wanted to have data prefill? Didn't know that.
Want your customers to be able to access their policy information online? Why didn't you say so?
Users assume that the project teams already know their needs. That's not always the case. In fact, often, the teams don't know.
More times than not, users see the software for the first time during training, not earlier in the project when requirements are being elicited or when the software is being designed and configured. Not even when the testing is being performed. The avenues for user input is limited, resulting in less-than-stellar software.
"The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later." —Frederick Brooks
No surprise. If the users are not engaged, the requirements—the users' needs—will not be understood. What happens in these projects whether taking a traditional or agile approach? The missed requirements are discovered later. And, the rework starts, resulting in adverse impacts to the project schedule and budget, as well as the team's morale.
Project teams complain that users don't know what they want and constantly change their minds. That may be true—sometimes. But, what would you expect when the users are not asked for their input earlier in the projects? Furthermore, we live in ever-changing industries that requires that we be able to handle changes.
I know that you're smarter than the average Joe. You know that doing the same thing and expecting different results is insane. Let's take a powerful and decidedly different approach.
Some project managers make timely responses to risks, resulting in positive progress toward their project goals. Others act haphazardly, resulting in undesirable consequences. Let's look at some common risk response mistakes and how to overcome them.
So, what do I mean by risk response mistake? A mistake is an action that is misguided or wrong.
"If you treat risk management as a part-time job, you might soon find yourself looking for one." —Deloitte
Joe Cunningham once managed a project to implement a commercial-off-the-shelf (COTS) software solution for a bank. He and the team had identified the project risks, but they had failed to analyze the common causes of the most significant risks. Consequently, the team was responding to risks but missing the high-leverage responses.
Perhaps you are making mistakes like this one. But, you don't have to.
I've created a list of ten risk response mistakes. I'm sure that you aren't guilty of all. Read through them, thinking about one of your projects. Make notes where you might improve.
Consider using this list as a checklist for one of your current projects. Keep your risk management as simple as possible while ensuring that the responses are economical and effective. Scale your response plans as needed; do more planning for larger complex projects and less for smaller projects.
It's easy to miss project risks. And, until a project manager has identified the threats and opportunities, the risks cannot be managed properly. Projects rise and fall with the project manager's ability to properly identify and manage their most significant risks.
Project managers don't want to spend an inordinate amount of time identifying risks—rightly so.
Neither can project managers afford to miss the critical risks. Let's look at strategies to identify risks and save time when identifying project risks. You can choose and scale these strategies as needed.
1. Use a risk list. A risk list is a list of potential risks for an industry, organization, or company. Ideally, the risks are listed by categories such as schedule, budget, quality, and scope. For example, you could identify schedule risks using a schedule risk list such as:
2. Use risk categories. What can we do if we don't have a risk list? Try a prompt list, a generic list of categories used to "prompt" the identification of risks. Typical project risk categories include:
3. Identify internal and external risks. It’s obvious that we need to identify internal risks. However, project managers may fail to identify external risks. Out of sight, out of mind. For example, an organization may contract with a third party to provide products, services, and supplies. There is the temptation to forget about it.
Just because a contract exists does not mean that the project manager has washed her hands of these risks. The project manager is still responsible for overseeing the activities, making sure the contracted products and services fulfill the project’s needs and integrate properly into the project deliverables.
“The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one.” —Mark Twain
4. Perform top-down and bottom-up risk identification. With a top-down approach to risk management, the project sponsor (and sometimes senior management) declares which threats and opportunities matter. The benefit is that it provides a high-level perspective. The project sponsor defines the project goals and determines the business strategies to make it happen.
However, the project sponsor will not likely understand the project planning and execution risks. A bottom-up approach provides the advantage of getting the views of the team members and key stakeholders. An excellent tool for the bottom-up risk identification is the work breakdown structure (WBS). The project manager can work with team members to discuss the lowest level WBS activities in order to identify risks.
5. Perform risk reviews periodically. Remember—risks change over time. Imagine never having your vehicles checked or never having a physical exam by a doctor. Project risk reviews should be performed regularly. In addition, reviews should be performed for the following events:
Keep in mind, we are NOT trying to identify every possible risk. We are scanning the project environment to find the most significant risks. If done properly, these strategies can help us identify the critical risks quickly. Then we can take the next step—treat the risks.
Some project managers take a different approach - it's called wait and see. It works like this: Don't invest time (i.e., waste time) identifying and treating risks. When the uncertain event or condition occurs, the project manager would fix it—translate, the project manager and affected stakeholders would put out the fires!
Responding to issues almost always require more time and cost more money than identifying and treating risks ahead of time. Being disciplined and applying an appropriate amount of time and focus on risks can reduce project expenses, promote the project schedule, reduce stress, and help a project team achieve its mission.
Known and unknown, internal and external, upside and downside—risks are woven into the fabric of every project. Project managers can waste a lot of time due to poor risk management. In today’s article, let’s look at seven things not to do when identifying project risks.
Dan the project manager just kicked off a new project, adding stress to his life. He was already managing three projects. Now he had a new team, new goals, new challenges, and yes, new risks.
If Dan was like most project managers, he would wait until later to start the risk identification process. Why hurry? He had enough to do without jumping into the risk management stuff.
However, risk waits for no one. In fact, the project risk exposure — the level of risk due to uncertainty — is highest at the beginning of projects. Why? We know the least.
Dan is smarter than most project managers. He starts identifying and capturing risks as he initiates and plans the new project. He proactively asks his team and stakeholders to help him identify the things that may hinder or help the project. His teams benefit from his early focus on achieving the project objectives.Continue reading
I conduct online surveys to get feedback from project managers on risk management topics. Here’s one of the questions, “What risk management techniques would you like to know more about?” Survey participants often respond with: Nominal Group Technique (NGT).
The nominal group technique is an efficient means for identifying and ranking risks, as well as other items. It is brainstorming on steroids. Risks are collected from a project team. The risks are analyzed and ranked by the team.
The NGT is a powerful tool for larger groups. The technique saves time, engages participants, and reduces groupthink—a phenomenon where people set aside their personal beliefs and adopt the opinion of a group.Continue reading
Poor risk management is costly. Project managers are caught off guard by emerging risks. And these risks may turn into issues costing more time and money.
But, it doesn't have to be that way. We can identify risks early. We can assess and prioritize our risks, allowing us to make better use of our limited time.
Let's look at the cost of poor risk management through the life of Tom Whitley. We will discuss his mistakes. Lastly, I'll provide you with a simple project risk management checklist to keep you from making the same mistakes.
The Star Mutual Insurance Company (SMIC) hired Tom Whitley as a project manager to manage information technology projects. Although Tom missed a few deadlines, he implemented most of his projects, though small, on time and under budget in his first year.
Tom was promoted to program manager after only 12 months with the company. He was assigned his first SMIC program, a combination of projects aimed at helping the company achieve a consistent underwriting profit. The program included projects to implement a new imaging system, a new policy administration system, and a new claims system, each led by a different project manager.
Tom pushed the project managers to take action quickly. He wanted to see progress within two to four weeks.
When one of the project managers spoke of identifying, evaluating, and managing risks, Tom cut her short, “We’ll get to the risk management later. I want an agile approach with the minimum process.”
The senior management team praised Tom for the early action. The imaging team had started building workflows. Check. The policy administration team started developing the interface to the claims administration system. Check. The CEO told the board of directors that things were going well for the first two months of the program (or so she thought).
In the third month, significant issues emerged. First, users were continuously changing the requirements for the policy administration system. Second, Tom started having problems with the third-party vendor resources. Third, the test regions were unstable, making it impossible for the testing teams to stay on schedule.
Tom and the project managers were spending more time dealing with issues and less time preparing for upcoming project activities. Things spiraled out of control. Eventually, SMIC replaced Tom as the program manager. The CEO reported the problems to the board and promised to get things back on track. But, it never happened.
After two years of trying to get the applications implemented, the company terminated the program and wrote off $15 million in expenses. SMIC continued missing revenue goals while expenses rose sharply. The CEO was fired after the company was downgraded twice and after four years of underwriting losses.
“Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.” —Douglas Adams
Although this is a fictitious story, many project managers (and companies) fail to use risk management as an effective means of achieving their objectives. If you were leading the next program, what would you do differently? Take note of Tom's mistakes.
How about you? How would you describe the health of your projects? Review one of your projects with this checklist:
Are your projects rooted in facts or hearsay? Knowing the facts puts you in the driver's seat.
Why? Because the facts provide points of reference in which we can better judge the significance of things and where there is uncertainty.
So, where do facts come into play in risk management?
“Facts are stubborn things; and whatever may be our wishes, our inclinations, or the dictates of our passion, they cannot alter the state of facts and evidence.” —John Adams
When identifying risks, I write risk statements using this handy-dandy risk syntax: Cause —> Risk —> Impact. No need to get overly strict with the syntax, but it does provide a practical way to think about your risks.
Risk management gets a lot of fanfare, but many project managers fail to cash in on the benefits. Here are some simple and practical project risk management tips that can aid project managers in getting better results.
“The first step in the risk management process is to acknowledge the reality of risk. Denial is a common tactic that substitutes deliberate ignorance for thoughtful planning.” —Charles Tremper