Project Partners Blog

By Jason Ames, PMP and Kimberly McDonald Baker

Too often organizations make an investment in an Enterprise Project Portfolio Management (EPPM) system but they fail to recognize the full benefits. One of the reasons is that people fail to see an enterprise PPM solution as more than just a scheduling tool.

When used properly, however, an EPPM system can be a critical factor in driving business value, not only by making sure a project stays on schedule but also via ensuring that the right projects are selected, resources are used efficiently and decision makers have the information they need to drive corporate strategy.

Key Drivers of EPPM Success

1. Top down commitment, bottom up participation
2. All business systems talk to each other
3. Measuring what’s important
4. Determining which projects to start and when to shut them down
5. Finding the bottlenecks
6. Constant learning

This series of blog articles will address each of the above success factors.

Top Down Commitment, Bottom Up Participation

We all know the story: a week, month or even longer is spent putting together the perfect program schedule. The entire management chain has signed off, the customer has accepted the plan and everyone is happy… until the actual work starts and everything is thrown out the window.

What happens next is extremely important for the course of the program. Too often functional organizations create their own “pocket schedules” that have little in common with the official program schedule. You’ve probably been in meetings where a manager says “that’s not my schedule” and pulls out a spreadsheet with their new operating plan on it.

The purpose of a program schedule is to ensure the entire program team is on the same page, and that each group gets what they need when they need it. Everyone needs to be working in concert to ensure project success but if individual functions start working to their own schedule who knows what will happen? Imagine a wedding where the bride, groom and minister are all expecting the ceremony to take place on different separate days.

How can this be resolved?

1. The Project Management Office (PMO)or program office needs to own the schedule; no other single function should have authority to enforce schedule control. Other groups should indeed raise concerns but the PMO should be the ultimate authority for all program related decisions which include the schedule. With the PMO in control of the schedule all functions are accountable to work to the plan until the PMO or program office determines changes are needed.

2. Once the PMO takes ownership of the schedule they need to share it with everyone on the project. If the PMO expects everyone to work to the same schedule, they must allow every team member, even the most junior members, to have access. For small projects weekly emails communicating schedules will probably work fine, but for large complex projects, Enabling team members to access a live, online version of the schedule is far better. Many EPPM tools provide this functionality natively but too often it is under utilized.

3. Once team members have access to the schedule, they should be responsible for updating the status of their activities. Too often the project manager or scheduler is forced to chase down activity status information, reducing their ability to assist program management in finding ways to optimize the project and reduce risk. Team members should be able to update the status of their activities as well as charge time to each activity. Without active participation in the updating cycle, team members become detached from the project plan and operate in the proverbial silo.

4. Lastly, suppliers must be involved. Many projects include external team members. This is especially prevalent in government contracting. How do you incorporate your suppliers’ schedules? How do you communicate status back to your suppliers? As projects grow in size and complexity, so do the number of suppliers and partners. It is easy to forget that these partners are as critical to your project’s success as your internal team. When possible, suppliers should be treated just as you would treat your own team members: with role-based access. Provide suppliers access to the overall program schedule and their own detailed schedule and make them responsible for updating their status.

By Robert D. Anderson, CPA

An article by Adam Bookman provides an interesting perspective on why about 68% of IT projects fail to deliver the original desired benefits. He quotes from a study done by the Standish Group that identifies three primary reasons:
1. The initiative was outsourced to IT and not owned by the business
2. The right tool drives success
3. Best Practices represent the best starting place

Looking back over 20 years in the Accounting and Finance role at major US firms and another 14 years consulting with large international companies, these findings agree with my observations. The most successful initiatives have always been the ones where people in the direct operational area take full ownership and IT plays a supporting rule. The worst initiatives have been the ones solely driven by IT with no business buy in. Read the rest of this entry »

When projects go wrong, they generally go wrong at the beginning. As my experience is largely in the defense industry, most of the following is derived from those experiences. Poorly defined requirements lead to poorly defined statements of work and specifications which lead to unrealistic expectations both at the customer and at the supplier. This fundamental communications issue blights projects and affects them throughout their life cycle. Why do project teams make these same mistakes over and over and over? After scores of interviews and post-mortems in the last twenty years, it unsurprisingly comes down to poor practices and lack of discipline. Is this the project team’s fault? Only partly. Often it is the customer’s fault, particularly in the world of government contracts. That the US Government attempts to employ good project management practice is a given; however their shortcomings are three-fold.

First, the program managers may be on promotion track, and that means reluctance to admit to problems.

Second, the program controls / Earned Value organization seems often more interested in accounting than in project management.

Third, the persons developing the statements of work and technical requirements fail to make them both clear and realistic.

Let’s start with the last first, as that is where a project can be at risk from inception. The problem with statements of work for major development procurements is that the persons writing them often either do not know how to define the requirements, when the aim is inventing technology, or they may have a jaundiced view of requirements definition, i.e. they want to leave certain things “obscure” in order to maintain a degree of “flexibility” in the future or they want to “challenge” the supplier to create a “better” solution. The former circumstance is merely a fact of life, but the later creates misunderstandings leading to unnecessary changes, do-overs, delays, and increased cost without advancing the project toward the ultimate goal of providing what the end-user needs. Over the last twenty years I worked with several engineering managers who avoided stating firm requirements because of the mistaken ideas that firm requirements tied their hands or reduced “creativity”. This then is a warning sign for the risk identification process…ill-defined requirements mean greater exposure to both buyer and seller.

So how does the “seller” correct this when it means telling the customer the he isn’t really doing a good job? The IT services model of defining requirements through joint analysis and jointly agreeing on requirements is a good one, as is employing the intent of the spiral project life cycle model which allows the risky bits to be identified and resolved at the lowest possible cost. If the risks cannot be reduced, then the project requirements and objectives can be modified or, if the costs begin to exceed the benefits, then the project may be abandoned entirely. This again will require a close relationship with the customer and may be a difficult sell on the supplier’s part. It certainly is worth approaching when you find yourself in the vague statement of work circumstance. One successful technique is to put that reluctant technical manager in the seller’s situation by asking him if he would sign a firm, fixed price contract as a home builder based only on an artist’s sketch of the house. You can infer what to do with the analogy from there. Ideally, we would want that technical manager to hire us to design the house in addition to building it. However, he still must provide basic requirements for us, for him, and for the project to be successful.

Establishing plain, straightforward, and honest communications is the only method for dealing with the first circumstance, that of a customer project or program manager who, for whatever reason, doesn’t want to hear about problems, issues, and risks. This, for the seller, may be a no-win situation, but it is better to have warned the customer’s project manager and to have told him the truth rather than being complicit in a disaster. A manager friend of mine had a sign on his desk “Come to me early with a problem, and you have a partner in finding a solution. Come to me late with a disaster, and you have a judge.” I employed that thought literally when I sat the customer project manager chair. That was one of the first discussions I would have with the seller on a newly contracted development project. It may be painful, but it works, and the pain is short term, rather than a reputation destroyer.

Using earned value as a project management technique is essential. That the Government’s EV people come from a financial background may present a challenge when attempting to design, organize, and build a project that results in meaningful measurements and statistics. I found three things crucial in earned value management: objective measurements, a deliverable/product breakdown structure as opposed to a “product-oriented” WBS (this often required deviation from the government’s contract WBS or MIL-HDBK-881A), and using labor hours for EV measurements on labor efforts. I’ll discuss each of these in a subsequent blog.