Forward Momentum: Delivering Results

By Vicki Wrona, PMP

When it comes to projects, the classic definition of project success is to deliver a project on time, on budget and within scope. However, I’m not sure that definition is adequate. I think it’s time that we revisit the classic definition of success, at least with regard to projects.

If you’re like me, you’ve seen examples of projects which were delivered on time and on budget with the scope that was defined and requested only to find that the end result is never implemented or used. If the software that was developed during an application development project sits on the shelf and never gets used but otherwise satisfies the classic definition of success, we could say that we delivered a successful failure! After all, what good is the product if the end user never uses the technology or the application that we have developed?

Let’s take a look at the Millenium Stadium built in England. This particular stadium was built for a large event and was finished on time and on budget. Everybody hailed the project as a success when the stadium opened. It held that large event and then proceeded to sit empty and unused for a few years. (Note: the stadium is now used.) Is this project a success? For a while, it did not appear to be so.

On the other hand, we may be aware of examples of projects that have been delivered late and/or over budget but are now viewed as successful. One example would be the Sydney Opera House in Sydney, Australia. When the Sydney Opera House was unveiled, the project was seen as an embarrassment and a failure. The project took numerous delays, was way over budget and had some accidents resulting in deaths associated with it. But over time, this “unsuccessful” project has become the symbol of Sydney and a tremendous success. The opera house is impressive, used and loved.

Especially with regard to IT, we really need to revisit the definition of success. Delivering on time, on budget and within scope is not good enough. Too often we de-scope a project in order to deliver it “on time” and/or “on budget”, so it doesn’t often deliver all of the requirements that were requested. That is fine if everyone agrees to the change and to having a product with decreased scope, but it happens a lot. Also, we often don’t do a proper job preparing the end-user for this new product or service. Maybe we didn’t build a product that fully satisfied their needs after all. That’s a failure on our part. Maybe we didn’t provide appropriate and proper training. Maybe we didn’t give them time to get used to the new product or process or to get over their fears of a new system. Whatever the reason, it is hard to consider these projects a success if the application we developed is not actually being used correctly or at all.

What do you think? What would you propose to use as a new definition for project success? Let me know.

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?