It's All About Execution
Glen Justis, EOD Partner
A "program" is a collection of related projects. For example, they could all be in the same corporate division, or they could support a related purpose (e.g., a set of road improvement projects to reduce traffic). If you can't manage the underlying projects well, it's almost impossible to manage the overall program well.
I would like to share a story based on a program management issue I witnessed a few years ago. An industry colleague (we'll use the name "Peter") was delivering a progress report on his division's capital program, along with an updated projection for the remainder of the year. His boss was traveling and, conveniently, so was the department head responsible for the program. They were behind schedule, largely due to an unrealistic engineering schedule and shortage of construction crews. The clock was ticking. If they didn't complete the planned set of projects on-time, earnings would be adversely effected.
Peter was a relative newcomer to the company, and was proud of his group's recent strides relating to project oversight and controls. However, his division had a target on its back because it was receiving what some considered a disproportionate share of company resources, yet was coming up short. Naively, Peter figured he had a "pass" since he was a relative newcomer to the group, and he wasn't part of setting the original program schedule and budget.
In short, the presentation went horribly. The audience (other department heads up to the CEO) didn't care that the original program schedule was unrealistic. The audience didn't care about Peter's analysis of "what the schedule should have been" and how they were now doing a better forecasting job. They wanted detailed information on what was being done to get back on track. They wanted assurance that all possible efforts were being made. Instead, Peter focused on the numbers. Company leadership found this highly unsatisfying. Peter was toast, and was grilled mercilessly. In talking with him afterwards, it was clear it had been one of his worst professional experiences.
How could Peter have avoided this? After listening and trying to encourage him, he admitted to me that, "in hindsight, all the signs of a no-win situation were there." While he felt set-up, he also recognized that the appeal of having the limelight clouded his judgement when accepting the "Invitation" to give the presentation.
More importantly, how could Peter's division have avoided a schedule and budget that were detached from reality? This situation, like most business performance issues, came down to the strength (or lack thereof) in people, processes, and technology.
So, what are "best practices" in project management? Volumes of material have been created about project management processes and technology. The Project Management Institute (PMI) now recognizes eight distinct certifications relating to project management training. (www.pmi.org/certifications/types)
Clearly, much attention is being given to project management processes. But, what are the essential elements? How do you create the best odds of success when you conduct a project?
I don't know about you, but I'd much rather be "toasted" than become toast due to a project that falls short of expectations. Diligent execution of basic project management fundamentals can make a big difference in your success.
Here is my Top 5 list of best practices:
1) Clarify, document, and communicate project objectives
A successful project is one that i) satisfies functional requirements, ii) is completed on-time, and iii) is completed on-budget. A project charter is a tool commonly used to document these and related project objectives. A great project charter will be clear and relatively concise. Many sample charters can be found online, but not all of them are good.
2) Ensure that tasks and subtasks are thoroughly identified
A high-quality project plan will have tasks and subtasks detailed in at least three levels (this would be called a "level 3" schedule), and usually more. A great way to do this is to work together as a team to identify tasks and subtasks, and then group them logically. By working in a group, people will build on each other's ideas, leading to thorough task planning.
3) Be careful with resource availability assumptions
The most common reason I see for late projects is overly-optimistic assumptions for resource availability. In many situations, project team members are assigned to the project in addition to their normal 40+ hours per week jobs. This is a recipe for failure. In general, people are not going to work more than normal just because they are assigned to a project. If the project is more important, you must find a way to free them up. Tools such as Microsoft Project, that can interface with corporate calendars, can help with this.
4) Identify project risks and develop a response plan for the major ones
For each task, identify the primary risks that could cause schedule delays and/or cost overruns. For the biggest risks, develop a risk management plan that i) ensures that everyone is aware of the risk, ii) defines actions to reduce the probability of it occurring, and iii) defines response plans to reduce the impact should it occur.
5) If possible, set the project schedule and budget after the above steps have been taken
In too many cases, the project schedule and budget is set too early, and is based on optimistic views and insufficient information. True, it's a catch-22 to some degree. You can't move forward with a project before you have an idea of its cost and timing. The solution is to be very conservative in developing the initial schedule and cost estimate in the business case, especially for projects types that are new to the organization.
So, how do you get this done without spending excessive time? Here's where the Pareto principle (otherwise known as the 80/20 rule) can help. For each of these five items, there will be a small set of issues that most heavily drives the outcome. With experience, you can identify and focus upon the issues that will make the most difference.