Forward Momentum: Delivering Results

By Dr. Gerald Mulenburg, PMP

A major difficulty of project management is dealing with the inherent uncertainty involved. There are no perfect project plans, and there is little rationale for expending the time and resources needed to try to make them perfect.

Agile project management is one example that shows how reducing the amount of planning in a highly uncertain environment can provide more opportunities to deal with uncertainty as it arises over the life of a project. Other ways to deal with uncertainty in projects begins and ends with understanding what I call the three basic truths about uncertainty in projects.

I. Uncertainty exists.
II. Uncertainty results from incomplete information, or the unknowns involved.
III. Uncertainty ends when the unknowns are revealed.

Reducing uncertainty depends on understanding at least six key elements about it:

1. Point of view
2. Intention
3. Communication
4. Effort
5. Focus
6. Judgment

1.  Point of View
When thinking about project management, what is the right point of view to take? It depends a lot from where you’re viewing the project. Each stakeholder’s viewpoint is based on what they need or expect from the project.

-The customer and/or user view of what they need
-Management’s view of achieving some desired strategic objective
-The program manager’s view of the contribution to their program
-The sponsor’s view of how well the project is meeting its plan
-The project manager’s view of how effectively and efficiently execution of the work is being accomplished
-The project team’s view from how well they are being supported in doing their work

2.  Intention
Intention is how a project fits into each of these points of view. Due to differences in expectations of the various stakeholders, the total sum of the individual intentions for the project may not be wholly achievable, and some compromise is necessary among the stakeholders. The intention for the project is to try and balance the stakeholders’ intentions by first clarifying them, and then meeting them as well as is practical.

3.  Communication
Communication is the lubricant that makes a project flow smoothly. It is close to being an absolute that all problems on projects are due to some problem with communication. Effective communication begins at the highest levels where a project originates with the definition of what is needed and expected from the project. This need and expectation must be made clear throughout all levels of a project- from management through the sponsor, to the project manager, the team, and even to ancillary participants such as vendors and others involved in some way with the project.

4.  Effort
Effort of course is the dedicated energy needed for project accomplishment. This is not just the energy of the team doing the work, but the energy needed from all of the stakeholders to make a project successful. Effort doesn’t end after a stakeholder’s initial involvement is over; it is the energy continually added to the project throughout its lifecycle.

5.  Focus
Focus ensures that the energy expended on the project is done in the most effective and efficient manner: the right work is being done on the right things, in the right way, at the right time. This requires the project manager to carefully determine, authorize, and monitor the order of work being done, and how well it’s being done in meeting the agreed upon schedule.

6.  Judgment
The unknowns creating uncertainty in a project require making a lot of decisions;, not only in the best interest of accomplishing the project, but also in the best interest of the product of the project during its useful lifetime. There is little to celebrate in completing a project that delivers a product prohibitively expensive to maintain, or with an unacceptably short life. However, it is not only the judgment for decisions of the project manager and team that is involved. Judgment begins with management deciding on which projects to pursue and then following those projects through their development to ensure that adequate support is provided, when needed. These are, after all, management’s projects. Those involved in completing a project are only management’s instruments to accomplishing it.

I feel strongly that incorporating these six key elements into your projects will help to better understand and reduce the uncertainty involved.

On past projects, how did you use these six elements?

By Kathy Martucci, PMP

Editor’s note: This is the third post in a series about implementing PeopleSoft projects. The second post on initial considerations for PeopleSoft implementations can be found here. 

It’s no accident that there are two processes in Project Initiation and twenty in Project Planning according to the Project Management Institute.  Many organizations make the costly mistake of diving right in because there is “no time to plan”.  On the contrary, most projects fail in the beginning as planning efforts are sacrificed for “action”.

In spite of the organization’s impatience, it’s your responsibility as the Project Manager to educate senior management in the advantages of compiling a thoughtful and reasonable plan before jumping into project execution.  

What are the key points to consider when planning a PeopleSoft implementation? Here are some factors to consider: 

1. Scope Definition:  Even if the organization compiled the world’s best Request for Proposal for a suite of software, the process of reviewing and verifying those requirements (and discovering new ones in the process) is absolutely essential for the proper scope definition of a PeopleSoft project. Especially if more than one module is to be implemented, requirements must be considered in light of a tightly integrated system. For example, configuration of the budget and general ledger modules can have a substantial and often irreversible impact on the sub-modules of Accounts Payable and Accounts Receivable. It may be worth dedicated PeopleSoft training for the project team and subject matter experts to increase their understanding of the system in order to articulate those requirements more definitively. 

2. Work Breakdown Structure:  Once the requirements are fully understood and gaps between what is and what should be are clearly identified by your seasoned PeopleSoft integrator, the WBS can be crafted with a solid foundation. However, software configuration and modifications to bridge gaps are only two out of potentially hundreds of other work packages including the elements of communications, stakeholder management, quality, risk management, hardware procurement and set up, testing, and training. 

3. Project Schedule:  Once scope is fully defined and a solid WBS is in place, employ the best possible experts to define, sequence and estimate required resources and time for each work package. When you develop it to your satisfaction and present it to management, resist the temptation to meet their often unrealistic expectations to implement such a game-changing system within their timeframes. If the timeframe doesn’t meet with their approval, craft at a scope that will. Even though the notion of the Triple Constraint (Time, Scope and Cost) is losing favor according to PMI, it is still true in concept. Something’s gotta give!

If the above considerations aren’t daunting in and of themselves, that’s not all. There are seventeen additional processes (according to PMI, that is) that the PM should at least consider before Execution begins in earnest.  Again, it is your duty to lead your organization through these processes even while senior management is questioning what your team is doing all this time.

How will you convince your senior management to invest serious time and effort in the planning process?

By Vicki Wrona, PMP

I was working with a group of people recently and one of them said, “It’s better to have 80% on time than 100% too late.” I love that statement.  Let’s explore that today.

A life lesson in college

When I was in college, I had an accounting professor who gave tests that were almost impossible to finish in the time allotted. His attitude was that he would rather see your work and thought process on all questions for partial credit than have a fully correct and complete answer on some questions. Those students who worked through a portion of all questions scored higher than those who completed some of the questions fully. In his view, it is better to provide 80% of most things than 100% of some things.

This is a lesson in life. We rarely have the luxury of finishing our to-do lists, or even the necessary and critical portion of our to-do lists. We certainly don’t get to those tasks designated for “when I have some free time”. It is a reality that we often must complete as much as we can as best we can in order to survive.

Relating this to our projects, our work and our lives

Isn’t it better for our customers to roll out a product or service that fits 80% of their wish list rather than roll out nothing (in an effort to be perfect) and serve 0% of the need? We have the option to improve the 80% to 100%, but often we leave that product at 80% either because of constraints or because it turns out that the 80% was good enough. Either way, it’s still better than 0%.

How many bright ideas are still just that – ideas? Isn’t it better to provide something rather than nothing?

I realize there are exceptions to this statement and that in some cases, like hospital or public safety, 80% won’t do. But even in those settings, there are places where improvements make a difference, even when they are not perfect.

A Caveat

Note: This doesn’t mean that sloppy or incomplete work is good enough. I realize there are people who consistently perform at levels not quite good enough. In their haste to do more, they are really performing at closer to 40%-60%, not the 80% I am referring to. Fifty percent delivery only creates more rework for them and for those they work with. That is not what I am talking about here at all.

What do you think? Is it better to provide 80% of most than 100% of some? How about 80% on time rather than 100% late?

By Darrell G. Stiffler, PMP

Note: This is part 1 on PMI vs. ITIL.

The terms Project Management Institute® (PMI) and Information Technology Infrastructure Library ® (ITIL) are tossed about with the assumption that everyone has the knowledge and experienced to know what these two organizations are all about.  That would be a false assumption.

Based on an email I received asking for the basic difference and similarities between the two, I intend to do a high level explanation, with enough information to get you thru a basic conversation.  This will be a many part blog, as to hold you in suspense and make you eager for the next publication J (Did I mention you had to have a good sense of humor to be a good project manager).

PMI and ITIL are mutually exclusive, meaning you can have a performing organization using ITIL organizational structure without using PMI methodology OR you can have a performing organization using the PMI methodology without using the ITIL organizational structure. There is real synergy when both are implemented, endorsed, and supported by senior management. A very important point must be made. If Senior Management does not fully support the PMI approach and the ITIL structure, they both have a low probability of succeeding.

Let’s start off discussing the PMI. The PMI was established in 1969. It was originally formed by a small southern university to put structure to the construction industry. In 1981 the PMI Board of Directors authorized the development of the “A Guide to the Project Management Body of Knowledge (PMBOK)”. Subsequently the PMI and the PMBOK have become the de facto standards in project management. The PMI is all about a structured process approach to project management. I hear the word “project” tossed around very loosely in the business world. It is often misused, almost as often as the term “Critical Path”, but that is another blog. For an event to become a project it must possess three characteristics.

1)      It is “Temporary”; it must have a specific start and end date.

2)      It must, at the end of the project, produce a unique product, service, or results.

3)      The event must use “progressive elaboration”.

Those are the key requirements that make an event a project. If it doesn’t meet those standards it is an “Operational” event. Projects are a subset of Operations. ITIL is all about operational organization structure. The PMI with the PMBOK gives a project structure, organization and suggested process.  A process is “A series of actions or task performed to achieve pre-described output or results”. Process is one of the binding similarities between PMI and ITIL. The PMBOK is a kind-of a road map regarding how to manage a project. The basis for the process used in project management are the five process groups:

1. Initiating
2. Planning
3. Execution
4. Control & Monitoring
5. Closure.

And the nine knowledge areas:

1. Integration
2. Scope
3. Time
4. Cost
5. Quality
6. Human Resources
7. Communication
8. Risk
9. Procurement

By combining these process groups and areas of knowledge there are 42 processes that are used in the PMI approach to project management.

The PMI offers a variety of certifications. The most popular and most recognized is the Project Management Professional (PMP) certification.   There are in excess of 400,000 PMP’s in the world. This is a dynamic number that increases monthly. The PMP certification requires documentable years of experience in project management and must be able to pass the certification test. Most aspiring candidates assume that by reading and studying the PMBOK they can pass the test. One big caution, note that the title states that it is a “Guide”. This is a very important subtlety in the title. What the PMI is alluding to is that not all you need to know to pass the PMP examination is in the PMBOK.  You must have more knowledge than what is in the PMBOK.

After one reads or starts reading the PMBOK, the usual reaction is “this is all common sense, however if we did all these steps and filled out all of these forms, we’d be over budget and not have much accomplished”. I usually say at this point, this is about being a manager and using common sense for an approach.  You may not need all the forms and process to do your project, however don’t disregard some of the major steps. Planning is the key to success, whether you are using the PMI approach to project management or ITIL in your organization structure.

In summary, PMI and ITIL are both about approach, structure, and process. PMI is about “Projects” and ITIL is about “Operational Organization structure”. If you wish more information on PMI and PMP the official web site is http://www.pmi.org/. The next blog will be more about ITIL.

Originally published on Idea.com.