Project Partners Blog


Posts Tagged ‘PMP’

By Jason Ames, PMP

Concluding our discussion from the prior blog articles, we now address success factors number 4 and 5.

Finding the Bottlenecks

One of the big advantages to having an Enterprise Project Portfolio Management system is the ability to see how each project affects the rest of the projects. Project managers have been trained to look at the critical path of their own projects but do they know if other projects are impacting their performance?

Ask yourself these questions:

  • Do team members work on multiple projects?
  • Does your project share a facility with other projects?
  • Is your project dependent on another project’s output? Read the rest of this entry »

By Jason Ames, PMP

Continuing our discussion from the prior blog article, we are now ready to address success factor number 4:

Determining which Projects to Start and When to Shut Them Down

Selecting the right projects is as important, if not more important, to your success as executing projects efficiently. The projects you select should support your firm’s strategic direction and contribute to the bottom line. Once projects have been selected they need to be ranked against each other to determine which projects are the most critical and who will win when resource conflicts exist. Just selecting and ranking projects is not enough, projects need to be continually reevaluated to ensure that they still meet your organization’s strategic direction. Over time priorities change, new opportunities arise, project ROI decreases, so you need to know how changes effect your project portfolio and where to put your resources. Read the rest of this entry »

By Jason Ames, PMP

Continuing our discussion from the prior blog article, we are now ready to address success factor number 3 in the Key Drivers to EPPM Success.

Measuring What’s Important

Team members will work to what they are measured against, so it is important to ensure that you are measuring the right things and that management is encouraging the right actions. It does not make any sense for a team to spend lots of money on overtime when cost is the critical factor. Former UCLA basketball coach John Wooden used to say “Don’t mistake activity for achievement.”

When a program starts it is important to establish the measurement criteria. If your project has a fixed budget you should be targeting cost controls and allow your schedule to slip if necessary. If you have fixed deliverable milestones you do everything possible to complete them on time. Too often organizations measure non-value-added metrics.

What should be done to ensure this does not happen? Read the rest of this entry »

By Jason Ames, PMP and Kimberly McDonald Baker

Continuing our discussion from the prior blog article, we are now ready to address success factor number 2 in the Key Drivers to EPPM Success.

All Business Systems Talk to Each Other

An Enterprise Project Portfolio Management system is one of many business systems that an organization may use to improve its operations, but it must not live in a vacuum. An organization’s projects touch accounting through project costs and expenditures. Projects touch engineering through cost and material estimating, drawing releases and change orders. Service projects are affected when scheduling client engagements. Read the rest of this entry »

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. Read the rest of this entry »

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.