Forward Momentum: Delivering Results

By Darrell G. Stiffler, PMP

Note: This is part 2 of a 3-part series on PMI vs. ITIL. Read part 1 PMI vs. ITIL:  How Are They Different Part 1 here.

This part of the comparison is about Information Technology Infrastructure Library (ITIL). I am told that it is pronounced “idle”, like in “the idle rich” or “my car idles badly.” I personally do not like that pronunciation.  It conjures up a vision of people standing around waiting for the go home whistle to sound (does any company do that anymore?).  I and some other authors I’ve spoken with pronounce it like “I tell.” That makes more visual sense to me. I visualize some leader telling the troops what to do and how to do it. The leaders telling the troops what to do and how to do it is exactly what ITIL is all about. ITIL is a framework of Information Technology Operational Organization Structure.

ITIL is a framework of best practices for quality IT Services Management. IT Service Management is defined as the delivery and support of IT services to meet the business needs of an organization. The recommendations of ITIL were developed in the late 1980s (around the time PMI’s PMBOK® Guide was published). ITIL origination was in the United Kingdom Central Computer and Telecommunications Agency (CCTA) which later merged into the Office of Government Commerce (OGC). ITIL has been adopted and accepted as a global standard for IT service management since the mid 1990s. There were predictions in the late ‘90s that ITIL would sweep the IT industry and by 2005 it would be the core practice of any large organization’s IT world; however, when those predictions were made they didn’t anticipate the crash of 2001 and subsequent bad economics for the next 10 years. Had the economy not crashed, we would all know more about ITIL. The adoption of ITL is expensive in both time and money.

I suspect the seeds of ITIL began when portfolio managers began to complain that the IT department was getting too much of the budget and they weren’t getting the value that they wanted. The structure of ITIL is to set up the IT department as an independent business. One of the first projects, which should be treated as a project with all the PMI rigors, is to publish a Services Catalog. A list of reports, online applications, web sites, etc., which the IT department offers to the company and sometimes even outsiders of the company. The purpose is a statement to the portfolio managers, “if you don’t like our prices, check the competition and you will see that we are competitive.” Of course not all companies, because of proprietary and confidential information, have the luxury to go to a competitor; however, if rates are published there can be some comparison shopping. This can be a real advantage to a portfolio manager if the IT is not proprietary or confidential. It will allow the portfolio managers to consider outsourcing to vendors that can take advantage of shared resources with other companies. This can have a very positive effect on the company’s bottom line.

The heart and soul of ITIL is the service desk. In the good old days we called it help desk, but someone decided to jazz it up and call it a service desk because it really does do more than just take “I broke it” calls. The service desk is a Single Point of Contact for the whole IT organization, whether you are a programmer, network specialist, hardware repair or install specialist, manager, change control specialist, configuration management person or whatever. There are several sophisticated software packages and a heart stopping price to help you manage the service desk.

There were two ITIL versions – v2 and v3. V3 is the latest path and v2 is going away or gone.  ITIL has two paths to certification. Both paths begin with the”v3 Foundations” class. The two paths are Service Support and Service Capability.  Both end with the ITIL Expert and then ITIL Master. The Service Lifecycle is a more technical path where Service Capability is more of a management path. Both paths include multiple courses. As you take and pass the exam course you are awarded points, eventually allowing you to sit for the Expert and then Masters Certification. As with the PMP^® certification you must document your experience, which is necessary for the higher certification. Since this blog is a high level understanding, I won’t go into the listing of classes.

With the similarities in the use of process by both PMI and ITIL one would think they would be joined at the hip. Well, the challenge is that ITIL has its own project management approach called PRojects IN Controlled Environments (PRINCE) with the latest version called PRINCE2. The method PRINCE2 is in the public domain, offering non-proprietary best practice guidance on project management. PRINCE2 is a registered trademark of OGC. There are two PRINCE2 qualification levels: PRINCE2 Foundation and PRINCE2 Practitioner. PRINCE2 Foundation level is for those with a requirement to learn the basics and terminology of PRINCE2.

ITIL is a challenge to implement. The scuttlebutt is that you have to try to implement ITIL three times before you might succeed. It takes a great deal of commitment by the organization in time and dollars. There is essentially an organizational chart of roles and responsibilities that must be filled.  These roles and responsibilities are not easy to fill and generally take experienced and expensive employee types; however, with that said, once implemented and maintained well, the organization can be very effective. This gets a little confusing.   For more information the website www.itil.co.uk has been replaced by the Best Management Practice website and the official ITIL website managed by the Best Management Practice partnership.

The third part of my blog will be a summary.

Originally published on Idea.com.

By Bruce Beer, PMP

Note: This is the third post in a series on PMOs. Read part 1 What is a PMO and What Does It Do or part 2 PMO Business Value and Impact.

In the previous two blogs in this series we looked at what a PMO is, and the business value that they bring to a company. In this blog, I want to look at the considerations that might help you decide whether you need one. After all, they can cost a great deal of money so you should be sure there is a definite requirement.

First, let’s look at a standard project with a PM, several team leads, and various team members. The planning would normally be performed by the PM and team leads with possible input from senior team members or Subject Matter Experts (SMEs), and the plan would include the three basic baselines – scope, time, and cost, considering the other key elements such as risk, quality, resources, and communications, etc.

When the project goes into execution, the PM will normally have a weekly status meeting where he/she would determine the current status of milestones and deliverables (scope), how well this is being performed compared to the schedule (time), all relevant costs (cost) and would probably review risk. During this meeting he/she can implement corrective or preventative actions as necessary.

Now consider a very large project with several sub-projects. During planning there may be a need for a high level view of scope, time, cost, risk, quality, and resources covering all of the sub-projects. The sub-projects may each have a PM, so the overall PM is now managing a team of PMs plus the overall baselines of the project. This is starting to look like a Project Management team!

Now let’s look at a program with several or many projects. This is an expansion of the previous case, and unless the overall Program Manager is careful, it will be easy to lose control and become a statistic for project failures.

The answer for both of the last two cases is probably a PMO, elevating the functions that spread over multiple projects to a PMO team. This team will consider and evaluate the effects of one project on other projects in the program and, where necessary, institute proactive activities as soon as possible.

Other considerations for implementing a PMO include 1) possible resource efficiency improvements across the program and 2) a much improved change management process that evaluates the impacts of changes in one project on all the other projects before deciding to approve or reject that change.

So where is the line drawn between having a Project Manager and a PMO? A PMO can be relatively small, maybe the overall PM plus the individual project PMs, so although it may not be called a “PMO” it could be the embryo of a PMO. The larger the project or program gets, the more likely the PMO is to include:

• A risk manager to review risk of the overall endeavor
• A quality manager to ensure consistent quality goals and “look and feel” across all projects
• A scheduling manager to create the overall schedule, dependencies, milestones, deliverables etc.
• Other specialist personnel

Costs could be collected and reported at the PMO level as could overall status and progress reports, to give management the relevant level of detail they require.

Another major feature of the PMO is the customer interface, whether for internal or external customers. It relieves individual PMs from interfacing with the customer, but probably more importantly, it gives the customer one focal point of contact for the program rather than multiple individual PMs. The customer will be able to have a coordinated view and assessment of the program rather than having to piece together different reports from each project.

In short, there is a grey area between PM and a PMO and it is a subjective judgment as to when one morphs into the other. One big element of the decision whether to have a PMO or not is cost – both the cost of having a PMO and the cost of not having one (potential project/program failure).

Another type of PMO that can be deployed is at the company level rather than project or program level. Several major companies have PMOs not tied to specific projects, but to act as an oversight for all projects and programs being performed by the company. This type of PMO would normally contain senior PMs and might perform project audits at various stages of a project life cycle. They might define and implement project quality measures, tools, techniques, templates, etc. to be used across the company to provide a common “look and feel” for that company’s project deliveries. These senior people could also provide mentoring for the more junior PMs in the company. This type of PMO will be particularly interested in lessons learned from individual projects to provide improving project ability for a company. If a company does not have a methodology, tools, templates, etc. in existence, the PMO could be the entity to develop, train, and implement these standards across the company. The decision of whether a company should have a PMO or not is again a subjective judgment made by senior management and will be subject to financial justification.

Although this blog gives some pointers as to when you might consider having a PMO, it is a highly subjective judgment based on things such as the company’s risk and quality policies, financial justification, and requirement for improvement of project success over time, among other things.

How do you see a PMO benefitting your current project or organization?

Next in this series we will look at how you might establish a PMO.

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?