An expert is a fellow who is afraid to learn anything new because then he wouldn't be an expert anymore. -HARRY S TRUMAN
WHEN WAS THE last time you tried something new? Applied a new concept or technique in your daily work? Brushed your teeth in the morning with the opposite hand?
Not comfortable with too much change? Join the crowd. Too much change or change poorly conceived and administered is just as damaging as clinging to the status quo. But you already know that because in one way or another, you're involved with projects, and projects are all about change. So how do we know what to change, when to change, how to change? And how do we embrace change and internalize it effectively?
The Context for Change
Peter Senge in his book The Fifth Discipline (1990) suggests that to thrive, companies must be willing to become learning organizations; people must cultivate a mind-set that embraces learning, acquiring knowledge, and applying it intelligently to the challenges of their workplace. Senge describes learning organizations as "organizations where people continually expand their capacity to create the results they truly desire, where new and expansive patterns of thinking are nurtured, where collective aspiration is set free, and where people are continually learning how to learn together" (p. 3).
Any company that intends to remain healthy and competitive in an increasingly global and electronic marketplace must be willing to change, and it must do so based on solid learning and careful application, delivered in a timely and resource-effective manner. Senge continues to emphasize that in business climates of rapid change, the only organizations that will excel are those that are flexible, adaptive, and productive. This requires that organizations "discover how to tap people's commitment and capacity to learn at all levels" (p. 4).
So what does this mean for you? What if you're not the CEO or a member of senior management who sets policy that directly contributes to corporate culture? The concept still applies. Wherever you are in the organization, you have a circle of influence, and you are responsible for influencing change. Corporate culture is as affected by work attitudes and behaviors from the middle out as much as it is from the top down, and maybe more so. You can transform the way you and those you influence think about and do your work. You can incorporate an attitude of learning into your corner of the world. The ability to learn and apply that knowledge to accomplish effective change is the cornerstone of corporate life and growth, and it's everyone's responsibility.
Let's focus on how change is accomplished within organizations. For all but the smallest alterations in direction, change requires resources: time, people, funding, and supporting methods and tools. Substantive improvements and changes within a business are implemented with project initiatives, and that's where we begin: with projects.
The Old Way
Projects, project management, and project methodologies are common terms in today's business environment. Over the past few decades, project management has become one of the fastest-growing professions in the world. Up to 4.5 million people in the United States and approximately 12 million additional people worldwide view project management as their profession of choice. The Project Management Institute (2000) estimates that the U.S. public and private sectors spend some $2.3 trillion on projects every year.
We have become comfortable with projects. Attach an idea or opportunity to a strategic business objective with a convincing business case or link it to a regulatory compliance requirement, and a project is born. Assign a project manager, and charter this person with delivering the product or service that meets the business objective. Form a team, and let them work to the formula of their project methodology. The project manager is experienced. The project methodology is logical. We have people and funding and tools. What could possibly go wrong?
The Old Results
Statistics regarding project results are interesting-especially statistics on project failure, since many of them are published by consulting firms that pair these statistics with their particular diagnosis and accompanying remedy for the problem. Depending on the source, you can find estimates of project failure that range from 15 percent to over 70 percent. Of course we're never really clear on what "project failure" is. Sometimes it includes cancelled projects, late projects, and projects that never reached completion. Does that imply that a project that reaches completion equates to "project success"? Not necessarily.
Jim Johnson of the Standish Group notes that even within efforts that are "completed," cancelled, unused, or underused functionality makes up as much as 29 percent of all projects. "A lot of times the company just gives up, or the business has changed so much, there's no point in going forward," he says. Of the remainder of projects counted as less than successful, 46 percent belong to the category he calls challenged, meaning late to market or experiencing a cost overrun. These projects may come to completion, but not in a way that was anticipated. The Standish Group (1995) found that for challenged projects, more than a quarter were completed with only 25 to 49 percent of originally specified features and functions.
Despite statistics old and new warning us of the potential for project failure, we continue to be surprised when things go wrong. And we keep on walking the same project path over and over again despite results that should lead us to question what we have learned.
In his book Radical Project Management (2002), Rob Thomsett suggests that in traditional approaches to managing projects, "critical management issues such as quality, benefits realization, and risk are either completely ignored, or plugged in as afterthought" (p. xxiii). His observations continue to suggest that we are far from being learning organizations, as the foundational assumptions on which we have built project management approaches are rooted in understanding a business environment that no longer exists. "Concepts such as fixed requirements, long development timeframes, stable teams and technology, and passive involvement of project stakeholders who trust their expert project managers have become historical myths" (p. xxiv).
We walk the path, not realizing that our foundational assumptions for embracing that path no longer hold true. All too often the path rather than the results becomes our focus. We embrace a methodology, a way of doing things, and rigidly hold people to walking it. We create our own automatons who are programmed to follow a path without thinking and get rewarded for doing so.
Insanity has been defined as doing the same thing over and over again and expecting a different outcome. Just like the old comfortable dog, we walk the same project path over and over again because it is comfortable. It's the standard. We know it. We're doing what the company has asked us to do. It's familiar. It's also insane.
We fail to realize that we have established a culture that rewards mechanical adherence to a set of tasks. People aren't incented to think critically about their project work; they are incented to follow the standard accepted path. They aren't incented to build out quality deliverables with broad ownership that are well understood; they are incented to fill in the blanks and check off the list. Chris Higgins from Bank of America refers to this blind adherence to the project methodology as the "template production line." We don't incent people to think; we reward them for following the project methodology. If things go awry, the methodology becomes an easy scapegoat.
As long as we continue to reward people for executing tasks rather than the results they produce, we will continue to perpetuate the insanity.
So do we completely abandon the familiar and start over? Not exactly. No more than we should keep doing the same thing because it's familiar. The point is to learn from project experiences and apply this learning intelligently. Learn where things went right and where things went wrong, and search out new techniques and approaches to enable improvement.
We certainly have more than a few excellent methodologies available to support business change and project approaches. Six Sigma, Lean, and other customer-focused quality methods provide blueprints for recognizing when change is needed and guiding us through the steps to accomplish it. The Project Management Institute's guidelines for project management (2004) also provide sound advice. So it's not for lack of methodology or process that projects are failing.
The People Side of Projects
In a recent book on the subject of productivity, George Eckes (2003) comments on a study that finds that "the majority of time project teams fail, the primary root cause is poor team dynamics.... A more common stumbling block is how a team conducts its work, and the dynamics of the team. Thus, it is our hope that we can review the keys to improving what, for many, is an elusive target-having groups of individuals work together to achieve what they could not achieve alone" (p. 2).
Yet this awareness is far from new. In 1987 Tom DeMarco and Timothy Lister pointed out that the major problems in accomplishing project work are not technology based or task based, but rather people based. Our ability to manage projects to successful completion is much more about tapping into the collective knowledge of people than managing to a predefined project methodology and set of tasks.
Best Practices conducted a benchmarking survey (2000) to be a directional indicator of project management trends. The study was designed to understand the project performance of companies that are renowned for their project management operations. Most of the companies surveyed tend to conduct more than 100 information technology-related projects a year, with 21 percent conducting more that 150 business projects per year requiring information technology components. Among the findings regarding what were the most significant causes in project delays were communication and planning factors, including lack of proper communication and cross-organization input; scope creep; and incomplete business requirements. Inadequate input from technology resources during early phases was noted 26 percent of the time.
All of these have their basis in people and their ability to communicate, make decisions, and share information throughout the project cycle. Choice of project methodology or use of a nonstandard project methodology was rarely cited as the cause for project delays (5 percent) (Best Practices, 2000).
The Methodology Myth
So if we've learned anything, perhaps it is that project success is not predictable and certainly not repeatable simply because we have a popular project methodology in place, embrace a standard set of deliverable templates, or follow a logical work breakdown structure. Finding the right people and ensuring their productive participation in the project effort-that is, knowing when and how to engage the right resources in the right way to gather the right information-remains a significant challenge.
In support of project efforts, we must first and foremost focus on people. We need to apply creative ways to engage the right people effectively because that is where competitive advantage has its basis: in the knowledge and ideas of people. What does a project have to implement if not the ideas of people translated into work products that serve the needs of customers? Yet we often get caught up in executing the project and miss opportunities to get people involved in a manner that enables them to contribute their best ideas and knowledge at the right time.
What Facilitation Has to Do with It
This focus on the contribution of people challenges the traditional model of the project manager as the driver of tasks and of the project manager or team member being a single builder of project deliverables, with occasional input from an available business resource. It introduces the need for an additional skill set to be applied within a project lifecycle: the skill set of facilitation.
Facilitation is a discipline that enables bringing people together to accomplish a specific outcome in a determined period of time. Its application to projects, especially information technology projects, is not new.
In the mid-1970s, Chuck Morris of IBM embraced an innovative way to get groups of people together to design and implement distributed systems. This application of facilitation techniques gave birth to the JAD era-that is, joint application design (JAD) work sessions where business and technology professionals came together to jointly define requirements for the design of computer systems. Use of facilitated group techniques (JADs) reduced time by 40 percent while improving the quality of design results. Fewer coding errors were made and testing cycles improved accordingly (Wood and Silver, 1989).
The creative application of facilitated group work sessions in support of project initiatives has not been widely practiced within traditional project approaches, however. Facilitation within the project lifecycle is a new application of a proven concept that supports project delivery by providing specialized skills and techniques that focus on people and their collective knowledge. Facilitation enables us to engage the right people throughout the project effort to obtain the joint input of business and technology experts at the right time to build the right work products.
Several of our clients found that introducing facilitated work sessions into the project has a two-stage effect on acceleration. The first point of acceleration is realized when building the targeted deliverable that is the focus of the work session. The second point of acceleration is noted downstream, where this deliverable is used in later project phases. The quality of this deliverable can eliminate rework in later phases, thus accelerating the project further.
Is this the only way of accelerating projects and introducing quality and ownership? Absolutely not. But does it work? Absolutely. Capers Jones, in his 2000 book Patterns of Software Systems Failure and Success, found that facilitated working sessions provided a number of tangible and intangible project benefits. The tangible benefits included:
Reduction of the risk of scope creep from 80 percent down to 10 percent
Acceleration in the early project lifecycle phases (including scope initiation, planning, definition) by 30 to 40 percent
Reduction of the overall project elapsed time and workforce effort by 5 to 15 percent
The intangible benefits are similarly impressive-for example:
Ownership of results
Improved working relationships
Shared decision making yielding informed decisions and support of these decisions
Summing It Up
Whatever your project process or methodology, strive to foster a learning environment in every project you touch.
Encourage listening, questioning, and learning. Eliminate indifference, complacency, and hanging on to the status quo. Be willing to consider something new that incorporates a significant learning, and reward those who do so.
Recognize that the key element to successful change is people. Look for new ways to involve them creatively in the project process. Involve those who can influence others.
Search out opportunities within your project to use facilitated work sessions that can tap into the joint knowledge of your resources. Bring this knowledge to bear at specific points throughout the project to improve the timing and quality of project deliverables.
There is no cookbook for achieving the benefits noted here, but we've got a good set of ingredients. Read on to see how this fits into the project lifecycle.
Excerpted from Facilitating the Project Lifecycle by Janet A. Means Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.