Agile, innovation, and the project manager
Global competition and unprecedented economic turmoil have created demanding innovation challenges for companies, industries, and nations. Change is occurring at an astounding rate. What role, if any, does professional project management have to play in leading innovation efforts while dealing with change? Many believe that project management is a hindrance to innovation, but the mistaken belief is found in the actual practice rather than the potential value. This paper will look at the role of project management methodology, particularly “agile project management” as applied in the context of software teams in fostering and enhancing innovation projects and their results. Based on eight years of leading an agile team that focuses on innovation projects, the author will relate the principles and practices of a high-functioning agile team to time-honored elements of A Guide to the Project Management Book of Knowledge (PMBOK® Guide) 4th Ed.
Introduction – Change is “In the air!”
Have things really changed that much? Are we truly experiencing change at a greater rate today than at other times in human history? Sometimes it is helpful to reflect on just how much the world has changed in recent years. How many of us remember: film, travel agents, landlines, readers guide to periodical literature, and newspapers.
The last 25 years have witnessed the birth of the personal computer, the Internet, social networking revolutions, and many other technology based innovations. Each successive increment of Moore's Law (Wikipedia, 2009) doubles the capacity of basic computing power and storage while reducing the size and cost of various hardware options. The era of faster, better, cheaper hardware brings with it a dark side: complexity and high expectations. Sophisticated and demanding customers have high expectations for fast delivery of ever higher quality innovations. The cost of switching from one supplier to another has never been lower, leading to a viciously competitive environment. The future belongs to those companies that innovate well and innovate quickly.
The question arises: What role does professional project management have in leading innovation projects? Often, traditional project management approaches are overwhelmed by the speed, ambiguity, and demands of today's innovation initiatives. Yet, without professional project management, many innovation projects stumble. These projects fail to keep executive management support, fail at critical time junctures, and fail to deliver the quality, scalability, and sophistication in demand by business and consumer users. The Information Technology (IT) industry regularly suffers massive project failures. The bigger the project, the more likely the failure.
We need new approaches to project management without abandoning the timeless principles of project management excellence. “Agile Project Management” and “Agile Software Development” are two oft-used and oft-abused buzzwords in business today. There is little doubt of the need for agility, but what is agility and what form does it take when it comes to project management? Project Management Professionals (PMPs®) are schooled practitioners of the iterative nature of projects. Planning, executing, and measuring (in the form on monitor and control) while fostering good stakeholder communication, managing budget, managing scope, tracking time, and schedules, managing human resource development and needs, and controlling quality – when done well – are all things we attribute to project management excellence. However, even the most experienced project managers (PMs) feel the pain of being “under the gun” while adjusting to a rapidly changing economic landscape while undertaking even more compelling innovation projects.
It is possible to rapidly innovate while enjoying the benefits and value of professional project management. While valuable, an agile approach is not a panacea. All methodologies including agile methodologies do not, by themselves, solve any problems. Properly done, modern iterative and incremental approaches (a.k.a, agile approaches) expose serious, unanticipated problems sooner, while we still have time and budget to respond and change.
The Problem with Innovation
“There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new order of things…Whenever his enemies have the ability to attack the innovator, they do so with the passion or partisans, while the others defend him sluggishly, so that the innovator and his party alike are vulnerable.” – Niccolo Machiavelli, (1513) (Rogers, 2003, p.1)
If innovation is so fraught with peril, why innovate at all?
In many ways, the world of innovation exists in the spirit of the popular characterization of the three laws of thermodynamics: You can't win, you can't break even, and you can't quit the game. Departments, businesses, organizations, and nations must innovate or they wither. Mistakes will occur during the innovation process and many organizations have compensation systems that punish mistakes rather than reward. Many companies foster cultures and methodologies that systematically hide bad news until the last possible moment resulting in making one large, fatal mistake rather than a series of small, correctible mistakes.
In spite of this existing “mistake-averse” environment, the world is paradoxically rewarding small-mistake makers, and there are many more of them than ever could exist before. Thomas Friedman recently reported that the “World is Flat.” (Friedman, 2005) The basis of his book of the same name is that 10 “world-flattening” technologies have leveled the playing field around the planet and thus we now “enjoy” competitors from every corner of the planet who have easy, inexpensive (in some cases free) access to technological advances that used to only be available to the great research and development (R&D) powerhouses of our time. How many of us still remember the great Bell Laboratories®, for example? Global companies now have access to world-wide free video teleconferencing (e.g., Skype), open-source software tools and libraries, search engines such as Google and Yahoo!, and other powerful information technologies, available on $200 laptops with amazing productivity software that is often available as free services (e.g., GoogleDocs).
It is also now possible to raise awareness of such new innovations through no-cost search engine results as well as relatively inexpensive pay-per-click advertising schemes. It is now possible to invent something anywhere on the planet and promote the offering to a worldwide audience on a very small budget.
Is it any wonder that even our largest corporations and governmental organizations are feeling the pain of adjustment to a “new order of things”?
What are the qualities of innovation projects?
According to PMBOK® Guide, “a project is a temporary endeavor undertaken to create a unique product, service, or result.” All projects by their very nature will incorporate something new and different, or else there wouldn't be a need for a project. The difference with innovation projects is that they are meant to be disruptive rather than incremental. Creating a disruptive technology entails a new level of thinking about both the problem and the solution and thus challenges everyone on the team to step outside of standard approaches and invent something new.
The challenge with disruptive technologies and disruptive products is that every element of the result must be reviewed and reconsidered. For commercial products or services, this means that a new approach to marketing, product management, product development, product support, product distribution, product pricing, business models, sales systems, reward systems, and product usage expectations must be considered during the course of the project. For “internal projects,” similar (and sometimes even more daunting) challenges must be faced to “sell” a new idea and elicit new behaviors within an existing, captive community. Resistance to change is a natural and normal human tendency, even healthy. However, innovation projects challenge us to consider the age-old dilemma: “If we've done what we've always done, we'll get what we've always gotten.” This thinking applies not only to the project itself but also to the project management approach used to lead the project to successful conclusion.
In an innovation project, we must be in a constant mode of discovery while still making progress toward an ambiguous and ambitious outcome. The goal, therefore, must be to build what Peter Senge describes as a “learning organization” in his book, The Fifth Discipline (1990). We can use the power and adaptable nature of an iterative and incremental approach to both make progress and provide opportunities for practical feedback along the way. Our planning systems must then provide a simple way to incorporate this feedback without increasing budget or slowing down the project. For most, this seems like an impossible combination.
This combination of factors creates an overarching need for rich communication and fast decision-making, best supported by a fairly flat team organization. Maintaining high team spirit is critical and can be enhanced by rewarding obvious small successes, embracing mistakes made, encouraging learning and experimentation, while maintaining a ruthless focus on time and budget.
What are the agile tools that innovation project teams can use?
War rooms and Serendipity
Most of us have had experience somewhere in student or professional lives with having to hit an important deadline. When fear of the deadline loomed, we often began circling the wagons with our collaborators to shorten communication cycles and cross-check each other's work. A “war-room” environment where everyone is within eyeshot and earshot of one another, sustains momentum, minimizes “stuck” time, and creates a general esprit de corps that holds up well during the high tension times of tight deliverables.
A secondary and potentially more powerful effect of this type of work environment is the effect of serendipity. The effect of overhearing the ideas of others and using that as a spur for innovation cannot be underestimated. As William Pretzer, author of Working at Inventing (2001) describes Thomas Edison's Menlo Park, NJ. lab:
“Far from being the sedate intellectual environment characterized by library quiet, Edison's labs were noisy, crowded places that often seemed on the point of uproar.” (p. 56)
Co-located Cross-Functional Teams
The power of having everyone work in the same room can be enhanced further if various project team roles co-locate. For example imagine the software team where the project manager, the software developers, the business analysts, and the quality assurance team are all housed within eyeshot and earshot. Suddenly, working out problems that previously required lengthy, drawn-out meetings are now being solved using “voice technology”. The amount of intra-team emails drops dramatically and the consequent productivity gain is realized, thereby further sustaining innovation momentum.
Quick standup meetings can be used to keep everyone up-to-date with one another. Simple “call outs,” where team members indicate what they've recently completed, what they are currently working on, and where they need help (if any) can be a very powerful “catch basin” for problems not being solved through serendipity. These meetings should be short (less than 15 minutes) and should not attempt to solve problems, but rather identify problems and request help. Small gatherings around point problems after the meeting are where the solutions should be sought. This gets the right people together without trapping non-contributors in lengthy boring meetings that breed disengagement and depletes morale and energy.
Visualization through Wallboard Displays
Having work plans and project artifacts pinned to a wall where everyone can see them supports a much more effective communication system that keeps all team members on the same page. While shared-drives and intranets have their place in maintaining project artifacts, the principle of “out of sight, out of mind” is at hard at work in deadline-driven environments. These wallboard displays create an opportunity for rich visualization that is often lost in the simple 2-D world of 19-inch liquid-crystal displays (LCD) and intranets.
“Make Mistakes Faster” Attitude
The idea of embracing making mistakes is one of the more difficult aspects of agile. We have been conditioned from grade school through college to avoid making mistakes or else we'll get bad grades, which then translate into fewer opportunities. Societal and cultural norms are also a powerful force in this behavioral debate. Let us simply accept that if we spend all of our time avoiding making any mistakes, we would never get anything done. Thus, we know we will make mistakes. If we condition ourselves to make mistakes faster, we can correct them while they are still small and while there is still time and budget remaining to do something about the mistakes.
Many IT projects fail because they turn out to be one gigantic, slow mistake. Once we discover that a technology choice won't work, a planned implementation will not succeed, or that a user community will not adopt a solution, the budget and time are usually gone. By using an iterative and incremental approach to software projects, we provide ample opportunities to check our work along the way and make critical adjustments.
An important qualification to this “tool” is that we MUST distinguish between the value of iterative and the danger in releasing too many completed versions to an unsuspecting user community. The value of a short iteration is found in the ability of the business sponsors to validate and adjust plans while they see the software coming to life. It then becomes an important business decision as to which of these increments are released to end-user community.
Management's behavior will be a large determining factor whether this tool can be successfully used. If management's rhetoric is “embrace change! Make mistake faster!” but management's behavior is to express profound disappointment every time a little mistake is displayed, this tool will be abandoned by the team, and progress will slow immensely. The opportunity for innovation will then be lost.
High Sponsor Engagement
According to the Standish Group, loss of “executive management sponsorship” is one of the most common reasons for IT project failures (1995). The questions arise: “What tools can we use to increase sponsor engagement throughout the project? How could this work for large, lengthy projects?”
We must first recognize that sponsors of technical projects are seeking a business goal, not a technical one. We therefore must learn to bridge the communication divide between geek-speak and business-jargon. An iterative and incremental approach where sponsors regularly see and touch tangible progress is far superior to status reports, Gantt charts, budget reports, and focus-group study reports.
We must also find a way to engage sponsors in the planning process and thus must present them with understandable alternatives in the form of competing features as different price points. (To use a housing analogy: A three-car garage at $75,000 vs. a carport at $5,000). Too often, techno-babble filled, inflexible plans are presented to sponsors with only two choices: Yes or no. “No,” eventually becomes the most reasonable answer, especially if original estimates were low (which they usually are) and now time and budget pressures are all the executives can comprehend from otherwise incomprehensible status reports that usually translate to, “We're really close,” and “We've been really close for several months now.”
Weekly or biweekly planning games, “show and tells,” wallboard displays of progress, and the palpable excitement of an energized team can create opportunities for high-engagement of sponsors, even when things don't go exactly as planned. When “bumps in the night” occur, the sponsor feels like an empowered member of the team who rolls up their sleeves and helps find the solution rather than be overwhelmed by the problem.
Permission to Build a Learning Organization
“In the long run, the only sustainable source of competitive advantage is your organization's ability to learn faster than the competition.” - Peter Senge, (1990, book flap)
One of the key challenges of innovation projects is that we are working in markets and technologies that no one fully understands and thus confounds standard human resource practices of hiring people with just the right skills to meet the needs of the projects. With innovation projects we must be learning constantly, but we still must get work done. Most organizations run cross-training and mentoring programs in fits and starts, and organizational learning initiatives often stall as soon as the budget axe swings. Yet, without learning, innovation will not occur.
Is there a way to build learning into the system? During the last 10years, I have discovered the most powerful managerial tool I have ever been privileged to use. It is a simple concept to describe: We pair our team members to work on the same task at the same time, and we switch the pairs every week. To use a nuclear energy term: It is organizational cold fusion. I get learning, cross training, and mentoring every moment of every day while getting the project work done. Quality skyrockets, productivity goes through the roof, and team members are energized. On boarding of a new person takes five minutes, and project teams can be scaled up and scaled down to meet work demands on a week-by-week basis.
The great managerial benefit is that I am no longer constrained by the traditional “tower of knowledge” problem of having only one person on the team who understands a particular aspect of the system, who then becomes the bottleneck for the project.
As the chief executive officer (CEO), I am able to give the team permission to build such a learning organization. Without my explicit and enthusiastic support, the team would only be able to steal time for learning while no one is watching.
Many technical teams will schedule hours-long meetings to discuss and debate a particular approach, analyzing the merits and costs, arguing the efficacy and alternatives, considering the risks and the unknowns. It is often the case that a half-hour experiment could answer most of the same questions and eliminate most of the risks of the unknown. Often the answer found as the result of the experiment, defied the expectations of the experts.
Establishing a culture that regularly declares, “We don't know, let's run the experiment,” will produce far more innovations faster than one that says, “We're not sure, let's schedule a meeting next week to discuss it with the whole team.” A culture of experimentation will always outperform a “meeting culture”.
How does this relate to the PMBOK® Guide?
Professional project management still needs to manage time, budget, scope, and quality. All four can be very fluid in an innovation project but time and budget are usually fixed while scope is quite fluid. Quality must not suffer while these tradeoffs are employed. Thus, what PMBOK® Guide tools relate to this environment?
After initiation, the basic iterative life cycle of a project is plan, execute, monitor and control. For innovation projects, a faster cycle time is often necessary. Consider the overhead in a weekly cycle to:
- collect additional scope,
- estimate its cost,
- adjust authorized scope,
- recalibrate the project schedule based on new scope inputs,
- adjust team structure and knowledge,
- assess risk of new approaches,
- manage human resources,
- reduce waste,
- learn quickly from mistakes,
- plan quality, plan communications,
- develop human resource plan, and
- plan risk management.
By example, I will describe the application of PMBOK® Guide to innovation projects by describing a typical week at the Menlo Software Factory™:
As Menlo works on several projects at the same time (often seven to 10), the PMs must connect with each other once a week to plan resource allocations for each of their projects. A “factory floor manager” arbitrates the discussion, as there can be competition for human resources. Each PM declares how many people they need and of what type of resource (programmers, quality assurance (QA), High-Tech Anthropologists®). The PMs collaborate to determine who will fill each of these spots for the week taking into consideration experience, leadership, vacation schedules, and the needs of the project. Finally, specific pairings are determined (which is an excellent moment to explore team member knowledge and skill development opportunities.) This human resource management occurs each week.
Throughout the course of the project, requirements are gathered on handwritten index cards (stories), and screen designs are captured by our High-Tech Anthropologists® on large foam-core boards. These story cards represent the work packages of our system as part of an on-going work breakdown structure exercise. Each week the PM schedules a one-to-two hour estimating session with the assigned team, where the team works in pairs to come up with time estimates for each of the outstanding work packages/story cards (even those that have been previously estimated but not yet scheduled). The PM will receive several estimates for each card.
As the weekly iteration ends, the sponsor visits the team for an interactive status report we call “show and tell,” where the sponsors walk through each of the completed story cards and demonstrate the results to the team that just completed the work. This creates high engagement for the sponsor and great accountability for the team.
The sponsors then move from “show and tell” to “planning game” (scope authorization) where estimated work packages are selected. This scope authorization occurs each week, and usually plans well into the future. Thus, previously authorized scope can be re-evaluated for priority in light of new discoveries and demonstrated progress toward a goal. This weekly, transparent check-in and re-evaluation of scope authorization gives the sponsor visibility into schedule and budget challenges long before they are fatal.
Afterward, the PM creates a “work authorization board” on the wall near where the team is doing the work. It outlines who is working together, which story cards are authorized for work by whom, and what relative order they are to be worked on, ensuring that each week the highest priority stories are scheduled first. A simple, visual status system is then employed to denote progress on story cards. Yellow dots mean work has begun, orange dots indicate work is believed to be done and is ready for checking by Quality Assurance, red dots show blocked progress, and green dots indicate done.
Team members turn in weekly timesheets outlining how much time was spent working on each authorized story card. These “actuals” are then aggregated in a project history spreadsheet for use as comparables for subsequent project proposals.
This simple, lightweight repeatable and measurable system is used on all projects. Its transparency empowers the team and engages the sponsor. Mistakes are often made in estimating and execution, but the open and collaborative work environment ensures they are caught quickly while we still have time and budget to respond to challenges and come up with solutions. The resulting environment is energized and the work pace is sustainable. Our team works 40-hour work weeks and never works on weekends. If we need more done we add more people. In eight years, we have never had to deny a vacation request. Joyful teamwork leads to better innovation.
Professional project management has a place in the new innovation economy. The principles touted in the PMBOK® Guide are timeless and still valid even in a time of rapid change. What we need are lightweight, fast-moving versions of “plan, execute, and measure”. High-functioning agile teams have adapted to this need while continuing to honor principles. What is required is new behavior from experienced teams with unwavering support for a new approach from their executive management.
The agile PM will be in high demand as the pace of change in a hyper-competitive world makes new demands on even the most experienced.
Friedman, T.H. (2005). The World is Flat. New York: Farrar, Straus and Giroux.
Pretzer, W.S. (1989). Working at inventing: Thomas A. Edison and the Menlo Park Experience. Baltimore, Maryland: The Johns Hopkins University Press.
Project Management Institute. (2008.) A Guide to the Project Management Body of Knowledge: (PMBOK® Guide) 4th ed. Newtown Square, PA: Project Management Institute, Inc.
Rogers, E. (2003). Diffusion of Innovations. New York: Free Press.
Senge, P. (1990). The Fifth Discipline: The Art & Practice of The Learning Organization. New York: Currency Doubleday.
The Standish Group CHAOS Report. (1995). Boston: The Standish Group International, Inc.
Wikipedia (2009) Moore's law, Retrieved from http://en.wikipedia.org/wiki/Moore's_law
© 2009, Menlo Innovations LLC
Originally published as a part of 2009 PMI Global Congress Proceedings – Orlando, Florida