Skip to main content

Achieving Project Excellence: What

Written by Mike Morton on . Posted in Articles. 18 Comments on Achieving Project Excellence: What

Many organisations are working to improve their business processes in an effort to stay competitive. Most try to travel the ”Toyota Way”, using lean manufacturing approaches including, among others, “Achieving Excellence” (AE) initiatives.

Because of globalization and innovation imperatives, many of those organizations are plagued by projects, programs and portfolio activities in their AE initiatives. They then try to improve their project-oriented business processes, or whatever shadow of a project management process they might think they have. Hence, they mistakenly apply AE frameworks for recurring operations to project-oriented activities and processes. By doing so, they make a very costly mistake, similar to the one that was made when everyone tried to apply ISO 9001-1994 – a standard addressing manufacturing issues – to service industries.

Those who know a bit better include OPM3-type assessments and approaches to their AE initiatives. But, frankly, I am not that sure either that the OPM3 model is based on a proper understanding of “what wastes we are trying to eliminate” when we talk about implementing Lean Project Management processes. Lauri Koskela and Greg Howell, in their landmark article, The underlying theory of project management is obsolete1, published in the 2002 Proceedings of the PMI Research Conference, invite us to ask ourselves very relevant questions about this model. It should be read by anyone who thinks that applying blindly such a model will help his or her organization attain the Nirvana of Lean, World-Competitive Business Excellence.

It is easier to criticize the efforts of others, many of them trying to help each other in complete good faith, than to improve on them. The truth, however, is that improvements on mainstream PM models have already been offered by organisations like the Lean Construction Institute2. Alas, they are not well known, although the true wastes of currently used project management processes have already be identified and documented.

Wastes associated with recurrent production, as identified by Taiichi Ohno (the late father of the Toyota Production System), concern themselves mostly with managing a flow of materials. Opposingly, wastes associated with project work, as identified by Greg Howell, Lauri Koskela, my friend Hal Macomber3 and lately by Norman Bobek, who identified a ninth one4, concern themselves mainly with managing a flow of humans and of human thoughts. They are, including a tenth one of my own design (that I’ll explain in my next blog entry): 

  1. Not using people’s talents 
  2. Underutilized people’s skills and capabilities 
  3. Lack of relevant information (on what to do or how to do it) 
  4. Excess irrelevant information 
  5. Behavioural Waste (not listening, not speaking) 
  6. Not taking advantage of people’s thoughts (wasting good ideas) 
  7. Providing something the customer doesn’t value 
  8. Making do (working without the proper resources) 
  9. Saying No (resistance to change)
  10. Not managing perceptions

Anyone who wants to Achieve Excellence in project-oriented activities should have a very good look at this list, because those are the wastes associated with current mainstream project management processes; these are the wastes to eliminate to become lean. Thus, It would be a very good idea to add a measure of their current status in current AE or OPM3 assessment tools and then take action to eliminate them.

Furthermore, using PMI’s proposed IPECC (Initiate, Plan, Execute, Control, Close) recurring project management process loop – the essence of the PMBOK and a real stroke of genius – would be a very good idea for anyone trying to implement AE initiatives in their organisation. I see many of those initiatives going on; most won’t make it for lack of proper phasing, scope definition, work breakdown structure and target dates. They are not properly defined and planned, although they should be. After all, Achieving Excellence in manufacturing is a project-oriented endeavour…. and it is subjected to the same wastes as those found on any other type of project work.

What do you think?

1 https://www.projecttimes.com/wp-content/uploads/attachments/ObsoleteTheory.pdf
2 www.leanconstruction.org
3 http://www.reformingprojectmanagement.com/2004/08/15/394/
4 http://www.reformingprojectmanagement.com/2007/10/09/841/

Claude Emond is one of the founders and president of Qualiscope Enterprises, a project management consulting, coaching and training firm based in Montreal, Canada. He has degrees in chemical engineering from Canada’s Royal Military College (BEng) and Montreal McGill University (MEng), a MBA from Ottawa University, workshop leadership training from Le Centre Quebecois de la PNL, and is a certified PMP. He has over 25 years experience managing major public and private projects. He teaches project risk management in the Schulich School of Business Master certificate in project management and the PMP certification revision class for PMI, Montreal. He is one of the authors of the current PMI standards for Portfolio Management. Claude can be reached at [email protected]

Which Comes First, the Chicken or the Egg?

Written by Mike Morton on . Posted in Articles. 11 Comments on Which Comes First, the Chicken or the Egg?

Editor’s Comments

A valid and often asked question! In his article, Chicken, Egg, Process, Tool, Terry Doerscher poses it again and lays out his reasons for doing so. He asks it in the context of processes and applications, and takes a good shot at rationalizing which is the chicken and which is the egg. But, he says, in today’s heavily automated business environments, it’s often difficult to tell the difference between the tool and the process.

Chris Vandersluis wonders if we might profitably roll the clock back to the Guild system of 800 years ago. In his current piece, Bring Back the Guild for Project Managers, he asks, “How do I know who is a good project manager?” He agrees that there are worthy academic credentials and he recognizes the standards established by PMI, but he feels that the idea of the Master passing on practical training to the Student, as in the Guild system, still has value. See if you agree!

Our intrepid bloggers are back with their unique views on so many subjects that project managers have to face every day. They’re always interested in your feedback, so please drop them an email whether or not you agree with their points of view.

And please tell us what you think of this issue and what you’d like to see in the future.

Linking Change Management Processes to Projects Early

Written by Mike Lecky on . Posted in Articles. 12 Comments on Linking Change Management Processes to Projects Early

IT projects usually represent change, so why aren’t there stronger links to the change management process at the formative stages of projects? Is there benefit to connecting the dots between business case approval, aligning the project portfolio with corporate objectives and change management? You bet there is!

There are many who would say that business cases need to be approved based solely on the merit of their benefits, costs and the risks associated with them. This isn’t wrong. But just because it passes this bar doesn’t mean the project should be given authorization to proceed. To make it onto the project roadmap the investment needs to be both viable and fitting to the organization. What does it mean to be both viable and fitting? It means that not only does the economic upside of the project have to be good enough, but the organization must also possess the ability to do the work (or get someone else to do it) and to make it pay off.

This is where integration with the organization’s change management process comes into play. According to a recent Tripwire podcast 35 to 50% of time in IT operations organizations is spent on unscheduled work dealing with poorly introduced changes.

Effective change management processes have several features that can help projects get off to the right start. Let’s first consider the progression from business case to project initiation and then see how this fits with the change management process.

Once the business case is shown to meet or exceed the threshold for investment, a project portfolio analysis exercise can be undertaken to assess the investment as being both viable and fitting to the company’s strategic objectives. The project is prioritized against other projects vying for the same total project budget dollars. Then it’s given a placeholder on the project roadmap. Having a placeholder means resources may be made available during a window for the duration necessary and to the extent outlined in the business case.

Has anyone had the experience of a business case understating the cost and duration of a project? Before the project is even initiated there is considerable schedule, budget and scope risk.

This is where an effective change management process can help. And assuming there are portfolio management practices in place, this is where it gets grey for many organizations.

Ideally, before that placeholder on the project roadmap gets inked in, a few things should be in place to keep the risk profile of the project low. First, an initial cut of the project estimate (perhaps budgetary only) and time line with a preliminary scope will confirm the early pre-project cost/benefit assertions of the business case. Second, the rest of the organization needs to be tuned in to the impact of the change.

Using the nomenclature of ITIL (Information Technology Infrastructure Library) the change management process is triggered by an RFC (request for change). This initiates several activities involving all potential stakeholders, internal and sometimes external to the organization, to evaluate the impact of the proposed change in their area. This is vetted by the change board which has significant authority over when, and how, a change request is incorporated into the working fabric of the business processes.

While approving a change is a formal process, the act of developing an approach to introducing the change is facilitative and change management offers an excellent framework to support project managers as they develop the project plan. Visibility and participation is higher when project planning is integrated with change management.

IT project managers win big time when solid change management frameworks are in place. The structure of many of their planning sessions is already served up in readily understood templates to identify and assess the impact of the change. The business wins because budget, schedule and scope risks are uncovered early by the broad audience of the change board. Finally, those involved in the business processes win because new initiatives large enough to warrant a project manager are now brought forward by the change process, giving them a voice early in the project life cycle.

 

Mike Lecky is a consultant at The Manta Group, a management consulting company specializing in IT governance, Project and Portfolio Management, Service Management, Risk and Compliance. Mike has degrees from the University of Waterloo (BScEng), The University of Western Ontario (MBA) and the University of Liverpool (MScIT). He worked for 12 years in aerospace electronics and as a Project Engineer managed several general aviation and US Military contracts. He teaches project management online with the School of Applied Technology at Humber College. Now, with over 25 years experience, he is a PMP and an information security professional (CISSP) and has a broad range of program and technology implementation experiences in the high tech and service sectors. Mike can be reached at [email protected]. This e-mail address is being protected from spam bots, you need JavaScript enabled to view it.

 

Chicken, Egg, Process, Tool

Written by Mike Morton on . Posted in Articles. 10 Comments on Chicken, Egg, Process, Tool

A question often asked is how to sequence business process improvement initiatives relative to selection of a supporting application. General consensus from the customer’s perspective seems to be that process design should be undertaken first, followed by selecting the tool that best aligns to the resulting processes. The logic: We don’t want processes to be dictated to us by an application.

As a chicken that has been on both sides of the road, so to speak, I certainly have a deep appreciation for that viewpoint — no one wants to find their business needs compromised by software limitations. But, I have also laid a few eggs in the past by being a stubborn and myopic do-it-yourself customer, and my stance has been further tempered by implementation experience and best practice R&D the last eight years.

Certainly, in a perfect world, in-house staff would develop highly tailored processes specific to your unique objectives and the maturity level of your organization. Then, you would select an application, which would be seamlessly integrated into your processes at the touch of a button, and without a hint of compromise. But, to borrow from one of our customer tag lines, we don’t live in a perfect world, and that’s why you have vendors.

It’s also important to recognize that in today’s heavily automated business environments, it is becoming increasingly difficult to differentiate between the tool and the process when all is said and done. With all that as a starting point, let me share a vendor perspective on the question, and make a case for why process development and tool configuration should be approached as an iterative, partnered effort.

Take stock of your process expertise

When embarking on any process improvement initiative, you should begin by analyzing the depth and breadth of organic process design experience that you can bring to bear on the given subject area. While I don’t want to infer that organizations aren’t competent in process improvement, you only know what you know, and you need to be realistic about the depth and availability of in-house expertise.

You are better off than most if you have a process architect in your company that has personal experience developing a particular process two or three times in a few different organizations. More likely, this level exceeds the collective experience of the entire process improvement team. While you can read and research and go to conferences for a more educated perspective on the situation, it will do little to bolster actual experience. The question is; is this enough? If you choose to just go with whatever limited experience you have, it may not get you what you really need, and could cost you plenty if it ends up simply propagating past process design issues that you need to alleviate.

Standards, alignment, and when compromise is your friend

The need for significant compromise is most common in organizations that choose to rely exclusively on internal expertise to redesign their processes. That usually indicates they have been self-reliant about a lot of things for a long time, which can have consequences.

When vendors design products, they do so to accommodate the widest possible interpretations of the most popular and successful methods of doing business that their target customers employ. This means that the majority of our customers do not have to make compromises of a magnitude that jeopardizes their success or objectives. There will always be matters of preference, technical considerations and differences in how to go about it, but vendors cannot stay on top for long by repeatedly failing to support the critical requirements of the customer base.

The reason this is important for customers to recognize is that if you find yourself routinely asking products to do things that the leading vendors can’t accommodate, it could be an indicator that you are trying to accomplish something that is out where the buses don’t run compared to accepted best practice. This should constitute a big red flag to the selection committee and process design team.

You could be that rare organization that is so unique or complex, compared to the rest of the modern business world, that your requirements have not yet been addressed. More often it is an indicator of what I call the Galapagos Effect — a condition where the organization becomes isolated because it lacks participation in industry forums and does not consider other sources of outside ideas. The result is that processes tend to evolve into strange animals over an extended period of time.

By not using outside support when the time comes for redesign, you risk continued divergence from industry standards. Even if these processes are working for you, when it comes to finding a supporting application, you may be constantly forced to either heavily customize off-the-shelf applications, build your own, or do without — all of which are expensive and frustrating propositions. Like a carnival sideshow figure, a peculiar process can have great personality and be loved by its mother, but it will still draw concerned stares from the town folk and be difficult to dress off the rack.

Independent process consultants

If you are determined to develop you processes independent of a tool, and realize you need assistance, you will most likely go to a business consulting service to obtain more experience. Many of these are highly respected and very good at what they do — but most of them cannot maintain the needed depth and range of contemporary tool expertise on all the latest releases of leading software applications.

We are in such a cycle of innovation and competition these days that tool design completely turns over about every two years, so an independent consultant’s past application experience becomes quickly outdated. Besides, you haven’t settled on any one product yet, anyway.

Bottom line, application-agnostic processes inherently limit the level of detail you can initially develop. Configuration and workflow automation details of the selected tool will likely surface a lot of considerations that haven’t been addressed, and they may force some adjustment of the original process design.

I’m not saying using a third-party consultant is a bad approach to take — just be aware that process development will most likely be a two-phase effort, and you will still have to employ the services of the application vendor to provide technology expertise. Make sure you factor that into your budget and time line.

The case for parallel development with a full service solution provider

A good solution provider will be able to supply a flexible and full featured software product, as well as provide broad industry experience and a significant amount of product-specific process development and adoption expertise. For example, at the company I work for, most of our business consultants have likely been through where you are today at some corporation, in addition to personally leading numerous product deployments, including process design. They are bona fide Crouching Chicken, Hidden Process Ninjas.

Finally, the most compelling consideration that isn’t often recognized is the degree of process innovation inherent in today’s product design and support. While customers fret over concerns that they will have to compromise too much, they may fail to appreciate that application vendors have the greatest exposure to latest approaches on process design and efficiency — specifically, what works and what doesn’t.

This means we can suggest new approaches and insights into how best to accomplish process improvement and integration that were probably never even on the radar of the in-house team. Best of all, they are in tool-specific context, so there is less potential for friction between process and technology. This asset often far outweighs any perceived liability of tool compromises.

Recognize that processes and tools are interdependent. An iterative approach to process design, tool configuration and joint validation often results in the best balance between leveraging latest innovations and highly functional processes. It also allows you to perform these steps in parallel rather than in series, shortening the overall project.

No one knows your business and its needs better than you do, but a good vendor adds specialized competencies that few independent consultants or in-house staff can provide. By combining the two, there is greater potential for quicker, lower risk, and more cost effective results.

So, the next time you are evaluating how to approach a process improvement initiative, consider looking for a full service vendor that can provide not only software and technical expertise but also be a trusted process design and integration partner. Take as much time and care looking at these capabilities as you do software functionality, and insist that they come from a single source. This will ensure alignment and avoid your being caught in the middle between the consulting group and software provider, pointing fingers at each other if conflicts arise.

Hey, if this sounds self-serving, it’s because I know we do this right and I’ve seen it done poorly a lot. Besides, if your Mom and Dad had told you this stuff, as you were growing up, you wouldn’t have to hear it off the virtual street from the likes of me!

Terry Doerscher has more than 24 years experience in practical process development, project management, PMO, business strategy, and work and resource management in construction, nuclear and IT fields. Mr. Doerscher is the Chief Solution Architect for Planview, an Austin-based software company dedicated to creating project portfolio management solutions. Mr. Doerscher also writes a blog, Enterprise Navigator, where he frequently discusses issues pertaining to portfolio management and IT, http://blogs.planview.com/tdoerscher/.

 

Bring Back the Guild for Project Managers

Written by Mike Morton on . Posted in Articles. 13 Comments on Bring Back the Guild for Project Managers

Over the years one of the concerns I’ve heard most often from senior managers is, “How do I know who is a good project manager?”

It’s a sincere question and a subject that has been debated from many different perspectives. Several associations have argued that project management should be considered a career choice and, for many, it has become one. There are now courses in project management. Some universities offer masters degrees in project management. There are shorter, less stringent certification programs. There are also association certifications such as the Project Management Institute’s Project Management Professional (PMP) certification. And yet, there remains an uncertainty among senior executives over whether they’ve found the right person to manage their mission critical project.

It’s easy to understand why. Thousands of people have passed PMI’s PMP standards for example, but if we were to do a survey of them all we’d find a wide range of capabilities. Some of those people have 20 years or more of managing projects that are very industry specific. Others have only a couple of years of specific project experience. The PMP designation at least requires that you have not only passed a test but have acquired other “points” (known as PDUs) which reflect levels of education and levels of experience in the project management realm. People who write articles (such as this one) in a project management publication receive a certain number of PDUs for that effort. There are PDUs for years of scholarity, for working on a project in a project manager capacity or somewhere in the project management structure of an organization.

That sounds pretty good so far until you see that there are organizations that offer a five-day intensive training specifically designed to help you pass the PMP exam and successfully complete the PMP certification. If you’re a senior executive and you see that this designation can be accomplished so quickly, it is certain to make you discerning as you begin your new project.

Now, I am not saying that the PMP designation is not useful. Far from it. It is rapidly becoming one of the most recognized designations in project management and that can only be a good thing for those of us who have been in the industry for a long time. At the very minimum, you can be sure that people who carry the PMP designation have a common understanding of the terms and concepts of project management that ensures they can be integrated into a common project management environment. In reality it is not what the PMP is; it is what people assume it represents that makes room for mischief!

The same problem occurs if we think of a Masters Degree in Project Management. Someone may have spent two years working through course after course and have successfully defended a thesis on project management theory. However, just like the PMP, this does not ensure that this person is capable of managing any project at any time.

Even experienced project managers who have managed dozens of projects may find themselves out of their element if they are no longer in the same industry.

A few years ago I met someone whose formative project management years had been spent in the defense industry on multi-billion dollar programs. This individual was well respected in that environment, but had decided to leave to join a high-tech startup firm during the Dot-Com era. Suddenly projects with multi-month procurement cycles, where contract management was absolutely key, were displaced by projects that only lasted a few weeks at a time where schedule and time to market was the difference between survival and failure. Needless to say, they found themselves completely overwhelmed by this very different world and felt like they had to relearn everything they knew about project management.

Having thought about this for some time, I had the good fortune to sit down with some people who’ve been around the project management industry for years and someone brought up an idea that is so blindingly obvious that I can’t imagine how I haven’t heard about it elsewhere.

I say let’s bring back the Guild System. This ancient but revered structure uses the apprentice, journeyman and master hierarchy to gradually make sure a professional is of sufficient quality and skill to be unleashed on mankind.

The more I think of this, the better I think it fits. First of all, project managers consider themselves professionals and as a professional, the guild system is highly relevant. Secondly, there is a definite hierarchy of experience that makes a difference. I’ve often heard it said that a project manager isn’t really worthy until he or she has at least one failed project under their belt. In the guild system, a project manager apprentice could struggle, yet the overall success of the project would be guaranteed by the master.

We have many organizations that have adopted the “mentoring” model to make available a more skilled manager to coach a newer manager but there’s a big difference in most of these programs from what was always so in the guild system. In the guild system, it is the master who is responsible for the apprentice’s work. It is their reputation that is on the line for any output from the apprentice person. Here in the western world, we are often uncomfortable with this concept. We like the notion of empowerment and trusting our new employees. But, I can tell you from the perspective of many first time project managers, who feel they’ve been thrown in the deep end of the pool without a lifejacket, that they would welcome being an apprentice and having guidance.

The other thing that the guild system offers us is a career path. The master carries the responsibility to nurture the new entries to the guild, and to ultimately replace him or herself with another master who can function equally as well. The journeyman (or woman) project manager is considered independent – but even here, the master continues to exert influence, operating as a quality control for journeymen they have trained. Also, joining the guild would become a career decision.

This model of operation isn’t completely abandoned in today’s society. If we look at the medical profession, it’s very much alive. Here is a profession that understands that if people aren’t capable of bringing their education to effective practical use, they will be a danger to society so we see the world of Intern, Resident and Attending Physicians. Only after serving as an intern will you be considered for approval as a doctor.

While the requirements for project managers don’t need to be quite so stringent as those for physicians, I think there’s something of value there to learn.

While my idea of a Project Management Guild may be only a dream at the moment, there is nothing stopping mid to large sized organizations from adopting this kind of structure. All that would be required to get started would be to set up the Project Management Office as a center of excellence and have project managers go through an apprenticeship program before they’re given unsupervised responsibility for projects.

So I say, turn back the clock… Bring back the Guild!

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected].