Forward Momentum: Delivering Results

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 of a 3-part series 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.

By Craig Covello, PMP

I’m sure it’s been quite a while since many of us who have earned PMP certification actually studied the PMBOK in preparation for the exam.  It is not surprising, then, that we move forward in our careers as project managers utilizing our own style.  Some of that style may be based upon selective PMBOK concepts tailored to our unique personalities and skills sets.  But more than likely, much of what we do as project managers is based upon the corporate culture in which we find ourselves, particularly in larger organizations which develop their own sets of tools and techniques.  Nevertheless, having a point of reference, such as the PMBOK, is useful, if not comforting, because it attempts to foster continuity and standards within our profession. 

To refresh my memory, I recently reviewed old notes taken while attending a PMP boot camp several years ago.  The exam questions were based upon the following areas of project management knowledge: Initiating, Planning, Executing, Monitoring/Controlling, Closing and finally Professional/Social Responsibility.  Specific topics found within these areas include project charters, scope management, work breakdown structures, team organizational structures, cost control, quality control, risk management… well, you get the idea.  The list goes on and on.  And although these topics are presented in a generic, project-agnostic format, each is addressed in significant detail.  So much detail, in fact, that sometimes we may lose sight of one of the main roles of the project manager – looking at the larger picture and taking a reality check.  Allow me to explain.

I often work on innovative pilot projects that are proof of concept endeavors with specific objectives, deliverables and relatively brief timelines.  Accordingly, these projects have limited resources, not only in dollars, but also limited in scope, time and particularly limited in staff.  That last point should be underscored, because limitations in staff resources require the project manager to assume many roles and wear many hats.  Sometimes we might act as a second set of eyes for quality assurance.  Other times, we may get involved with finding technical solutions to specific problems.  And of course, we are always managing the project sponsor’s expectations.  So viewing the project from a larger perspective and applying proactive, commonsense judgment is a critical PM talent.  Yes, the templates, methodologies and concepts presented in the PMBOK are important, but remember that these are simply tools to be used at the discretion of the PM.  Projects are comprised of a unique mix of cultures, personalities, objectives and constraints that often cannot be approached mechanically in a “paint by numbers” fashion. 

To illustrate, I once worked on an innovation project sponsored by a rather large healthcare organization.  The vendor selected to provide the technology was a relatively small company with limited staff.  So limited in fact, that many of the vendor’s employees had roles and responsibilities that were somewhat blurred and interchangeable.  That said, it was not surprising that this vendor had some weaknesses in areas of quality control.  So I took it upon myself to act as an impartial Q/A analyst, if only for a few days.  By temporarily offering my services as a pinch-hitter, we were able to identify three or four critical errors in workflow and functionality prior to implementation. It was a reality check utilizing common sense in a proactive fashion appropriate for the scope and limitations of this particular project.  It could be argued that the responsibility for quality assurance belonged to the vendor, but in reality they had their plates full with too many competing tasks.  Only the PM had the larger perspective to assess the Q/A situation and identify the weakness.  And the temporary role assigned to myself spared the project for failure and also saved the healthcare organization from embarrassment.  The reality check allowed me to identify a need that might have been missed under a template approach with tasks checked off.

So make it a practice to take a reality check at least once a week.  Use your unique perspective as PM to ensure that issues are identified and resolved before they become someone else’s headache after implementation.  Don’t get lured into repetitive, templated motion.  In contrast, take time for some serious, objective assessment of the project’s status and health.  This habit requires insight and judgment, but then again, but that’s why project managers are put in charge.  That’s reality.

How do you remember to take a step back and give your project a reality check? How often do you do that?