Anything But Business As Usual

“Whenever a thing is done for the first time, it releases a little demon”
-Emily Dickenson

Something New
Have you ever seen a helicopter fly without a pilot?

In the early part this decade, NASA wanted to see exactly that. As part of their mission to advance US prowess in aviation, they launched the Autonomous Rotorcraft Project (ARP).

The ambitious goal of this project was to create an unmanned helicopter (rotorcraft) that would operate with the decision-making skill of a piloted aircraft. It would serve as a flying laboratory for unmanned helicopter flight, with advanced flight controls, a reactive planner, a digital vision system and real-time vehicle health management systems.

Most likely, you have never actually created an autonomous aircraft, but you may be surprised when the basics of this story may seem strangely familiar to you.

A lot of things would need to come together in order to make this idea a reality. Experts were needed from the specialized fields of helicopter dynamics and autonomous executive software development, to name a few. The team had to be pulled together from a number of military branches and NASA. Although most had not worked together before, they had to now, using the time and funding available to reach their goal.

To make sure that all this happened, NASA and the Computing, Information and Communications Technology Program (CICT) hired a project manager. This person would be responsible for developing schedules, budgets, reports, coordinating communication with all stakeholders, gaining approval on tasks, overseeing development of the product and conducting project risk assessments. The project manager would report to two supervisors, one from NASA and one from the CICT.

The project began with a process to clarify the stakeholders’ expectations and clearly communicate them to all project members. A “project charter” was created to define the scope and goal of the project. This document was then presented to the stakeholders, who negotiated all points with team members.

Based on these negotiations, the team incorporated the necessary changes, then defined and broke down the tasks that need be completed to meet the project’s goals. The next step was to decide on the order in which these tasks needed to be done and agreement of who on the team would be responsible for each task.

As the project progressed along this plan, the team gave regular demonstrations of their accomplishments. This technique kept the stakeholders interested, promoted trust and provided the team with milestones – smaller deadlines for the partial delivery of the work to be done.

The team carefully planned and maintained communication throughout the project. Aside from formal, periodic status reports, the project team and the hangar team were housed together to facilitate informal communication. Also, a web site was created for the project that could be used to communicate with anyone interested.

To combat risk, the project manager searched for potential weaknesses in the plans and prepared contingency responses to any major delay or crisis. Always mindful of communication, these risk management plans were shared widely so that many eyes could be used to identify risk and many hands were aware of the appropriate responses.

The project manager not only communicated the priories of the project clearly from the stakeholders to project team, but also sought each team member’s opinion to find the best possible solutions to the problems that they encountered. Although, sometimes, this would result in a change to the plan, the goal of the project was a priority over simply following a schedule carved in stone.

In the end, the ARP project was a great success. It satisfied all of NASA’s success factors and served as a stepping stone to funding for the 2005 fiscal year and future NASA projects. In 2005, the ARP team was nominated for PMI’s 2005 “Project of the Year” award, with full support from the NASA community.

Of course, this basic story seems familiar – ARP was a project. The word “project” is so familiar and so widespread that you hardly notice when it is used. But, what, exactly is a “project” and what sets it apart from the rest of the work that an organization does?

Different from Everything Else
To answer this question, let’s look at two separate definitions - each sheds light on the nature of projects and why they are so different from everything else.

First Definition
First, lets look into the definition for “project” provided by the industry standard “Guide to the Project Management Body of Knowledge (PMBOK®)- “A project is a temporary endeavor undertaken to create a unique product, service, or result.”

According to this definition, projects create something new. Although elements of a project may be similar, each project is slightly different in design, context, circumstances, clients, contractors, risks and issues. Second, a project is temporary endeavor. Projects have a starting date and end date. When the project’s goal is accomplished, the project is done. There is always an identifiable end point.

In many cases, when a project ends, the product of the effort is transitioned from the team that worked to create it, to the team that will manage, maintain and optimize it. This product could be anything new; a new business process, new system, new product or a new venture. This product is turned over from project management to operations – “an organizational function performing the ongoing execution of activities that produce the same product or provide a repetitive service”.

Generally Different
In a very basic way, everything that an organization does falls into either the broad category of “project” or “operations”. Work is done either to change the business in some way or to sustain it.

Of course, there are places where these pure distinctions blend. For example, producing a magazine that is different every month produces a unique output on a routine basis. The fact of the matter is, that a large amount of work is done on a continuum between being a pure project and pure operations.

Still, as blended as they may sometimes become, projects and operations are very different functions and even more different mindsets. To name a few:

• Projects are unique; operations are repetitive.
• The aim of operations is to sustain the business; the aim of the project is to achieve objectives.
• Projects are temporary; operations are ongoing.
• Operations are concerned with the maintenance of existing things; projects are concerned with the creation of new things.
• Projects are future oriented; operations are focused on the present.
• Operations views change as a problem; projects are change.
  

Specifically Different
It would only follow that the particulars of projects are also very different from operations. For example, in each of the following areas, project work differs significantly from operations.

• Authority – In a company, authority is clear- traditional structures are set up around operations processes. In a project, authority might not be so clear.
  
  The unique nature of projects often means that team members are drawn from cooperating areas across the organization. A single, vertical line of authority is relatively rare.
  
  If your team members have accountants, will it be the controller, or HR, or the project leader that will have effective authority. Who motivates; who gives promotions and incentives? Who disciplines? It can be confusing to both the project leader and the team member.
  
  
• Budgeting – Most budgeting activities are built around dictated accounting cycles. But, projects are driven by factors very separate from the tax year – if you are just starting your fiscal year and find that a competitor has developed an advantage, you cannot wait for the next budget cycle to react.
  
  Owing to the unique nature of projects, budgets are really estimates, based on much less dependable historical cost information than how much is spent to run any given department last year.
  
  Finally, since the scope of projects may change and projects may span multiple budget cycles or pass from one fiscal year into another, project budgets must often be reexamined, both for approved changes in what the project is to accomplish, and, in light of the changing fiscal realities of the organization.

• Staffing – Just as the project has a start and finish, so does the team assigned to them. Every project has different personnel needs. Some of the people might be temporary, part time, or assigned to other projects. Regardless of whether there will be dedicated personnel for the project, or personnel are on loan from the organization to initiate that particular project, the people need to be assembled at the start, and disbanded at the end. People are unfamiliar with their roles, and probably are not used to working together.
  
  Compound these issues with the fact that many projects may be run simultaneously, all with different durations and team sizes and you can easily understand the complexity of resource planning. Where will the people come from and where will they go?
  
  
• Accounting – Due to the result-oriented nature of projects, the sort of Generally Accepted Accounting Principles familiar in operations (cash basis) are different from project accounting (cash and accrual basis).
  
  For example, if a project is to result in the creation of a “viable” software asset, then certain types of costs are not expensed in the current period. Instead, these project costs are considered part of the cost of acquiring an asset not yet owned and should be expensed in the future after the asset reaches “operability”. As you might imagine, this has the possibility of leading to some interesting accounting “special effects”. (AICPA SOP 98-1)
  
  
• Communication – If a process is routine and familiar, it requires relatively little communication. In contrast, projects that require coordinated, concerted, temporary effort from a people across the organization are only productive when communication is made a real priority.

Second Definition
The second, considerably more elegant, definition of a project comes from 1950’s management guru J.H. Juran: “A project is a problem scheduled to be solved.”

Although this is less detailed than our first definition, it still speaks to the temporary, goal-oriented nature of projects from the first definition. More importantly, though, this definition highlights the role of projects in the organization and the typical mindset of the people who work on them.

Happy Problems
Simply put, the basic role of the project in an organization is to solve problems.

Problems may come in such forms as inefficient processes, products that lag behind the competition, aging software or achieving strategic objectives. In operations, the goal is to avoid problems - to produce a product or service with as little interruption or as little variation as is possible. In contrast, as Juran points out, “a project is a problem…”.

In their 2002 book, “Winning thru Innovation”, Tushman and O’Reilly make the point that,

“The most successful firms...do not wait for crises to occur; rather, their managers say, “If we don’t move now, we will be in trouble in the near future.” They proactively generate crises…by creating, and solving, problems.”

As they point out, a crucial component of strategy is the process of defining future opportunities and problems. Once the problems are defined, it is the role of the project to elaborate on the definition of the problem and work to find a solution. Accordingly, the project must both inform and execute strategy.

Given this definition, the expanded role of the project is to actively participate in the strategic process of proactively identifying problems and changing the organization to meet them.

Troubled People
The last part of Juran’s definition is the mindset of the people who work on projects. Just as projects are different, the attitude of the people who work on “problems” is different, too.

In operations, trouble is always bad. Things are going well only in the absence of trouble. Cool and smooth are the goals in operations. In contrast, you sign up for a project if you are looking for trouble – to get into the mix of applying yourself to solving a problem.

People who specialize in working on projects are typically focused on goals and enjoy the process of discovery to get to them. They can get bored quickly with routine tasks and enjoy understanding the “trouble” that the strategists make. They are typically less change adverse to their colleagues in operations and more focused on a promising future than a comfortable present.

If you are a strategist, project people are the ones that will most appreciate the work that you do. They are motivated by the problems that you identify and are quickly engaged in finding solutions.

Like the work that they do, these people are different.

The Definition of Success
In operations, success is fairly easy to define. When nothing bad happens, there is no interruption of service or manufacturing, operations is successful. However, the success of project is somewhat harder to define.

Traditionally, projects success was gauged by three metrics, “the iron triangle” of (1) time, (2) budget and (3) specification. This view might be tidy, but, unfortunately, the reality of project success is somewhat more complex.

Project Failure
In 1986, the Ford Taurus was unveiled and went on to both redefine the design of modern cars and rescue the struggling Ford Motor Company. It was such a commercial design success that, within a few years, the design had been copied by most car makers all over the world and people were complaining that all cars were starting to look like the Taurus.

The project team was as innovative as the car that they produced. Unlike the conventional design process where the engineers, stylists, manufacturing engineers and marketing people did only it’s own work before passing the design “over the wall” to the next group, a team approach was adopted for the project, bringing all of the different groups together. As a result, communication was improved, designs were better integrated and the car was less expensive to manufacture.

This team also “benchmarked” the car, identifying the best design features on the market and trying to improve on them for the Taurus. Also, great emphasis was put on the design for low cost manufacturing and quality was made the first priority.

The result was a huge winner in the marketplace, saving Ford Motor from disaster brought on by higher gas prices, foreign competition, dated product design and poor reliability.

Taurus was named Motor Trend’s “Car of the Year” for 1996 and Car and Driver’s “Ten Best” list for the same year. By the end of the 1986 model year, over 200,000 Taurus were sold. By the time production of the first generation of the car ended in 1991, over 2 million Tauruses had been sold. Finally, in 1995, Henry Ford gave the “Edsel B. Ford Design History Award” to Team Taurus.

In retrospect, the Taurus design project produced as good a result as could be imagined.

However, at the time that it was completed, Ford considered the project such a failure that the project manager was demoted for overrunning cost and schedule by more than three months.

Project Success
The night sky in the fall of 2000 was scheduled to feature a dramatic show of human-made shooting stars as the satellites fell to earth and burnt up from the failed Iridium project.

It wasn’t only going to be gravity doing the dirty work bringing them back to Earth - the satellites were going to be instructed to fall, years ahead of schedule, because of the financial failures of the program. In the words of William Kidd, an analyst at C.E. Uterberg, Iridium resulted in the creation of “some of the most expensive space debris ever”.

When the project started, Motorola envisioned Iridium as a constellation of 77 low-earth satellites that would allow for world-wide satellite phone service available from portable handsets. In the words of their 1998 press release, “The Global Village just got a lot smaller…Iridium will open up the world of business, commerce, disaster relief and humanitarian assistance with our first-of-its-kind global communications service…The potential uses of Iridium products are boundless.”

Unfortunately, when Iridium was rolled out, fundamental issues were immediately realized. The phone was too big and too heavy. At $3,000 a handset, it was also hugely expensive and often couldn’t even be used inside. Worse, during the time that the project team and management was consumed with the ambitious technical goals of the project, they failed to recognize and react to the huge growth of the expanse of cellular networks that were beginning to cover the globe, eroding away the customer base that the project was to eventually serve.

When Irridium finally failed, they had less than 60 thousand subscribers, world-wide - less than 1,000 subscribers per satellite they launched.

Regardless of the financial outcome, the size, scope and efficiency of the Iridium project was nothing but impressive. The science exercised in this effort was at the top of the field and the innovation was truly revolutionary.

The team was able to take a space industry, almost entirely focused on defense, an application that required absolutely fail-safe systems and their associated cost overruns, and repurposed it for commercial use. All of the conventions for building a spacecraft were changed and the cost of building a satellite was reduced by a factor of 10.

The successful project management effort to pull together a large and diverse team of contractors, investors and other stakeholders was equally impressive. The coordination and management of this effort was unprecedented as an example of successful execution of a project of this ambitious scope and complexity.

The construction and launch of this extensive network of satellites and the development of phone handset technology was certainly justification in the minds of the investors for the billions of dollars and the 11 years that it took to build it.

It was too bad that the project team had solved the wrong problem. - As Peter Drucker put it, “There is nothing so useless as doing efficiently that which should not be done at all.”

Although the technology was ultimately rescued by the military, the Iridium corporation failed as a result of this project. In August of 1999, only 10 months after the Iridium service became commercially available and two days after they defaulted on $1.5 billion in loans, the Iridium corporation filed a Chapter 11 bankruptcy that would be one of the largest 20 bankruptcies in US history.

Mission Accomplished?
Obviously, meeting schedule, specification and budget is only a small part of a much larger picture when it comes to gauging the success of a project. In fact, the success of a project can only be measured by the value of what it creates.

Since this simple statement is the seed of so much new thinking about Project Management and the core concept of this book, let me say it one more time:

The success of a project can only be measured by the value of what it creates.

If the strategy is incorrect and the result of the project has no value then the best executed project has no value. Some might argue that the success of the project and the success of the product need to be examined separately - that a project can be a success even if it creates something useless.

But, obviously, this is not what hard-won experience tells us.

Like the Taurus team, both strategy and execution must be examined and managed during the course of the project’s execution. Strategy is not enough, tactics are not enough -there must be a feedback loop between execution and strategy. The project’s role must be both to move efficiently towards the resolution of problems and to make sure on an ongoing basis that the right problems are being solved - it must do the work right and do the right work.

In the end, the real success of the project is determined by how well the effort contributes to the organization’s goals. If this statement is true, the bottom line is that projects are part of the strategic management function of the organization - they are strategy that lives and breathes.

Next
Just as projects are different with their own set of complexities, contexts, risks and definitions of success, a different management discipline has grown up to manage them. In the next blog post, we will explore the body of knowledge that has evolved around crucial skills necessary for successful execution.