Forward Momentum: Delivering Results

by Vicki Wrona, PMP

In the spirit of continuing my discussion of the evolution of project management, this month I will describe the evolution of various professions as I have seen it occur. I have found there are a variety of conflicting opinions here. I welcome different perspectives on this, so please share your views.

I started working in project management in the 1980s to a limited extent while working at LTV Aerospace and Defense, continuing to evolve my project management skills at American Airlines and then for clients served by my company, Forward Momentum. The profession that I fondly think of as project management has now evolved into multiple professions.

Let’s start with project management and its certification. Project managers have a choice when becoming PM certified. One of the most globally recognized certifications is the PMP® certification managed by the Project Management Institute. PMI was founded in 1969, the PMP® certification was first offered in 1984 and currently there are approximately 500,000 PMPs worldwide. The core body of knowledge is called the PMBOK® Guide (A Guide to the Project Management Body of Knowledge).

The first evolution that I experienced from project management is one that Karey Rees discussed in her post Project Manager and the Business Analyst: Who’s Who. This is the Business Analysis skill or profession, with its own certifications. Business analysts can become CBAP® certified, which is maintained by the International Institute of Business Analysts. While the business analysis skill has been recognized and developing for many years, the IIBA was founded recently, in 2003, and is the first organization to offer certifications for business analysts. The CBAP® certification is newer and is becoming more popular with currently approximately 2400 CBAPs.  The core body of knowledge is called the BABOK® Guide (A Guide to the Business Analyst Body of Knowledge).

In my experience and as Karey Rees described in her article Project Manager and the Business Analyst: Who’s Who, some organizations still expect their PMs to perform the function of the business analyst, one area of which is to define, document and manage requirements. I have often filled both PM and BA roles on a project. Other organizations have a separate and distinct career track for BAs vs PMs, often with little to no overlap.

Another, more recent skill or profession is that of the business architect. Where the business analyst is a smaller, logical extension of the PM function, a business architect role takes a larger leap, involving a wider scope and additional skills. The work of the business architect has a longer life cycle than the project manager or business analyst, encompassing the work of both the BA and the PM along with a strategic, and often sales, aspect. (Those from a project management background may relate to the business architect as a program manager who has responsibility for strategy and possibly sales, along with defining requirements and completing the project.)

Since this profession is a young one which is still being defined, there are multiple frameworks, including the Business Architecture Guild’s Business Architecture Body of Knowledge Handbook (BIZBOK™), The Open Group Architecture Framework (TOGAF) by The Open Group and the eXtended Business Modeling Language (xBML) framework.

If you are like me and have been working in the project management area at least a couple decades, you can look back over your working career and realize you did some or all three of these professions, if not in name, then in function. That is certainly true for me. How about you?

If you are interested in exploring these topics, please see our course list.

If you are interested in getting project management certified, check out our CAPM® or PMP® Exam Preparation courses.

by Vicki Wrona, PMP

I listened to a webinar recently regarding the future of project management. This webinar, called Project HEADWAY: Is There Anything New Under the Sun? Opening up the View of PM, was hosted by projectmanagement.com (formerly www.gantthead.com) and conducted by Mark Mullaly.

One of the points I was happy to hear is that project managers must go beyond simply defining how to deliver a project. Instead, they need to better understand why the project needs to be done and how to align all stakeholders to the underlying reason and benefit of the project. To do this, the project manager must fully understand the industry, type of project being undertaken, organizational culture, and the processes and tools possible to develop an approach that will work for that particular situation.

Project management is not a set of tools or templates that can blindly be applied equally to all projects. Instead, the approach developed for each project must be tailored to that project, with equal care given to the tools TO use as well as those NOT to use.  In addition, the PM is now expected to deliver value. They are more often being held accountable to develop, understand and deliver the business results rather than simply being told the contents of the business case.

This feeds nicely to one possible future direction of project management. One recent trend is that getting certified will no longer signal the end, or epitome, of a project management journey. Instead, it now signals the beginning of the journey. The certification itself demonstrates a working knowledge of the profession, after which the PM must cultivate the specific skills necessary to deliver success and value applicable to their particular industry, organization and project type. They must use these advanced and niche skills to consistently deliver project success beyond simply being on time, on budget and within scope. They must also deliver business value.  In the end, project management becomes a necessary core competency within an organization, adapting to and becoming integrated with the internal culture.

There are two other future and distinct directions of project management that Mark covers in the webinar. I will let you discover those for yourself at http://www.projectmanagement.com/webinars/273410/Project-HEADWAY—Is-There-Anything-New-Under-the-Sun–Opening-Up-the-View-of-PM. If you listen to the free webinar, you will earn one PDU.

Let me know what you think about 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 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?