Forward Momentum: Delivering Results

By Rob Zell

How is learning delivered in your organization? Would you say it’s “pushed” (often used with “down” or “out”) or does it follow a “pull” model in which team members access it at will? Either way, your learning department is working hard to make sure that training is available as needed to support the business, and that’s a good thing. Furthermore, the best in class organizations are doing both, providing just in time training to meet immediate needs and optional offerings to advance knowledge and skills.

Organizations that follow a “push” only model are going to rapidly fall behind the curve and will soon find themselves lagging behind the competition. In the current business environment, companies need to have innovative, forward thinking leaders and requires a culture that fosters experimentation, exploration and critical thinking. Your organization can certainly hire for those skills but it’s an expensive model to support and you might be better served growing talent from within the organization.

Compliance often drives a “push” model of learning. In organizations with a high need for safety, security, internal accountability and regulatory compliance, training reflects the need to ensure that employees are certified for legal reasons. Historically, this follows a traditional model of education. Primary and secondary schools modeled the factory model of the industrial revolution, demanding homogenized groups and standardized levels.

Instead, I propose to maximize the effectiveness of learning in your organization you should be looking at three categories of training:

1.  Compliance Training. We’ll call this “Mission Critical”, training that meets regulatory compliance or is necessary to keep the wheels on the bus. In my experience, things like food safety, OSHA training, information security, Patriot Act and, for front line employees, training required for cash management, point of sale, and inventory management. In some organizations, ethics courses and diversity training fall into this category based on the culture. These types of courses fit well into the “push” model and are considered ticket to entry into the organization.

2.  Development Training. Let’s call this “Nuts and Bolts” training. This set of courseware advances the knowledge and skills of the organization in various functions. Content areas in this curriculum cover topics like leadership, project management, merchandising, human resources management, real estate development, logistics and customer relations. These courses can be developed in house or outsourced and may be linked to university or certification programs for transferable credits. By delivering this content you raise the knowledge and skill level of your people which increases the bench strength and long term survivability of your team. These courses fall into both “push” and “pull” categories. Learners engage the content as needed for their own development and growth in the organization but managers can always prescribe a course of learning to help move employees along or ensure accurate execution.

3.  Personal Training. This is the “Bells and Whistles” content. This is my catch all bucket for anything else that people want for their own learning plan. These courses support personal development and fill in the gaps to improve personal performance. Courses on time management, communication and organizational skills or experiences and roles that provide experience through trial and error. These should be primarily “pull” programs; employees self-identify areas of improvement and seek out learning opportunities to enhance their performance. In some cases, managers may prescribe specific courses or experiences based on need.

A solid learning program should have all three kinds of content, delivered via various modalities. Some sessions are best served through classroom sessions (in person or virtual classes) while others might be online courses, self-study documents, or peer sharing networks. Having a menu of content and delivery options provides access to the necessary training for success.

How is training structured in your organization? Is all training served up through a “push” model, a “pull model” or a combination of both? What do you find to be the most effective way to ensure employees are receiving the content they need, when they need it?

By Darrell G. Stiffler, PMP

Note: This is part 2 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.