Forward Momentum: Delivering Results

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.

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?

By Bruce Beer, PMP

Note: This is Part 2 in a series on Project Management Offices. Part 1, What is a PMO and What Does it Do? can be found here.

In Part 1 of this series, I outlined what a PMO is and what a PMO can or should do. Now let us turn to the business reasons and incentives for having a PMO. A PMO is often packed with senior and expensive resources so there has to be a good business case for this expenditure.

Not all programs can justify the cost of a PMO. However, consideration has to be given not so much to the cost but to the “value” of a PMO: things like how much does it influence the success of the project, how much money can it save, how much additional cost would there be and could the program objectives be successfully met without one, etc. So let us look at some of the features of a PMO and how this could be cost justified.

Baselines

At the project level we have three key baselines: scope, cost, and time. It is the Project Manager’s responsibility to establish and then meet those baselines. In a program where there may be multiple related projects, each of those projects will have their own baselines and there may be a Program Manager who is in overall charge. However, the Program Manager has a finite limit regarding the number and complexity of projects in the program that they can manage alone. It will not take long for the Program Manager to start recruiting additional resources to assist in managing various aspects of the program. It also does not take long for this to escalate and morph into a PMO, whether recognized or not.

Constraints

One thing most projects will do is to evaluate constraint priorities – the flexibility matrix. What is the key “driver” for each project – time, cost, or scope/functionality? If different projects have different priorities there is a high chance that the program will not be totally successful due to conflicting project priorities. If, for example, the program is time driven, the whole program must be complete by a certain date. Unless each individual project understands that time is the key driver and if they focus on one of the other constraints instead, they could cause the program to slip. So enabling a time driven program to coordinate and amalgamate individual project schedules and milestones will enable identification of the program’s critical path, ie which projects are on the critical path. The PMO can then ensure the focus on these projects is to attempt to ensure critical timescales are met. This could provide major benefits to a company in terms of reducing cost of slippage of a time driven program and have a direct impact on the bottom line of the program and the company.

If the program level critical path changes, the PMO should be aware of this and shift their focus to the new critical path projects, so again maximizing the chance of overall success. Missing a time deadline can have serious financial implications for a company, and the reverse is true – meeting contractual or defined deadlines can save or gain additional revenue.

Information and Reporting

Without relevant coordination and management of the constituent projects at the program level, senior management may not be able to obtain a consistent view of the program objectives and status without a lot of digging. Consequently, one of the major functions of a PMO would be to gather information from the constituent projects, combine these disparate objectives, plans, status reports, deliverables etc. into a set of higher level overall program information for easier understanding by management. These reports should indicate developing issues at the earliest time, together with any action required to put a program back on track.

Risk

Some tasks that the PMO will undertake at the program level may include overall risk management – assessing how a risk on one project might impact other projects. If a risk starts to happen on one project, the PMO can immediately assess action required on other projects to minimize “knock-on” effects.

Quality

Ensure a consistent look and feel for each project under the PMO and provide templates that can be used to ensure the constituent projects look like they are coordinated and are not just a mixture of random projects thrown together. This may not have a tangible bottom line benefit but will improve the final product of the program.

Managing a Program vs. a Company-Wide PMO

All the above considerations were in regard to multiple related projects in a program. Now let us consider a “company” PMO where the PMO is not managing a program of related projects but is there to provide assistance on all projects being undertaken by the company. Many of the benefits detailed above also apply to this scenario, but there are also additional considerations.

Having led a PMO for a major computer company, I can highlight some of the benefits. Before there was a company PMO, all projects were little “islands” of work. The company wide PMO was staffed by several of the most senior PMs in the company and the main roles of the PMO were to:

• Train all PMs in the company methodology – this was compulsory for all PMs.
• Provide a consistent framework to review all potential projects to ensure that any response to an RFP that the company submitted had considered all the relevant areas of the plan, had achievable baselines, and risk was contained.
• Provided the framework for Quality audits or reviews of all major projects in execution to ensure consistent application of the company methodology, in particular financial, time, quality and risk management.
• Provide a formal mechanism for mentoring less experienced PMs.
• Allow for consolidated monthly reporting on all projects to assess any problem areas and attempt to even out risk among all company projects.
• Provide templates and tools that could be used not only throughout the USA projects but also were accessible globally.
• Implement a standard and comprehensive change management process for all US projects.

In conclusion, there are many quantifiable benefits of having a PMO for both a group of related projects in a program or as a company-wide function to improve project management over time in a company. There are also many intangible or “soft” benefits of a PMO such as common standards, methodologies, tools and templates, etc. that will have an eventual impact on the bottom line of a company even if they cannot be quantified at the individual project level.

The next post in this series will look at why you might want a PMO and at what stage you could think about creating one.

By Rob Zell

I had a boss once who loved to draw on the white board. It became something of a joke on his team, that at the beginning of a meeting we would hide the dry erase markers before he came into the room. It never stopped him; he started carrying them around. Only recently do I truly appreciate his approach.

Sidebar for a personal story: My daughter’s soccer team recently ended their season and part of my end of season gift was a coloring book and crayons and the missive that it was something to help me reduce my stress (something of a gag gift). At home after the party, I sat down with the coloring book and colored a picture. I took the time to work slowly and carefully, experimenting with different colors and used shading to highlight areas. It took me back to a calmer time: I worked on the image for me, not for my boss, or my kids, or for the executive committee – just for me. I loved it.

I am known among my peers as the visual learning guy. I push hard on the team to use fewer words and more pictures in both the training materials we produce and the presentations we create. If an image is worth a thousand words then we should we be creating voluminous training in images, not pages of text. Too often, the push back is, “I can’t draw” or “I’m not creative.” Let me say now that everyone can take this approach given some processes and tools.

1. Take some time to tap into your creative side. A quick search on Google yields a plethora of sites on coloring to relieve stress. I’m not saying you should make it a daily habit, but why not take a few minutes once in a while to doodle? It unlocks a thinking habit that thrives on free association and random connections that you might not have considered. Those links are the foundations of innovation and might lead to bigger and better ideas.
2. Incorporate a process for thinking differently. The Six Thinking Hats framework developed by Edward de Bono is a wonderful starting point for organizing meetings and encouraging a style of thinking. Assign the role of Green Hat to various team members and have them work at being the creative, “blue sky” thinker. By assigning the role to a person you give permission for ideas to flow and remove limitations.
3. Encourage mind-mapping as a technique for organizing information. On many occasions I find myself in meetings struggling to grasp how all the parts of a program or initiative are tied together. The various stakeholders have input into the problem and the resulting maelstrom can be hard to decode. A mind map can help illustrate the interconnectedness of all the ideas and make concrete the linkages that the entire team needs to see.
4. Seek out visual representations of complex ideas. I have two sites I visit regularly to keep my mindset firmly planted in a visual approach. One is the RSA.org channel on YouTube. This British think tank does a fabulous job of linking thought leaders to artistic displays of the concepts. The images drawn in the videos make the presentations so much more vivid. Another is visual.ly a web site that shows how information can be presented visually and, in my opinion, more memorable.

Finally, let me say that visuals don’t have to be high end art work to be effective. A very simple visual can speak volumes to the reader and communicate at more levels than a paragraph of text. Visuals are great for learning, meeting management, brainstorming, even project management (what’s a WBS but a visual of all the tasks in a project?). Don’t fear the creative side, embrace it and take your projects and work into a different, better, more holistic place.

How are you using visuals and creativity to work more efficiently in your role? If you aren’t using them now, how could you?