The article is currently under copyright by Nexbridge Inc., © 2001. All rights are reserved.
No material from this article may be reproduced electronically or in print without written permission from Nexbridge Inc.
For permission for commercial or educational use of the content of this or any Nexbridge publication, please leave a comment below.

Introduction

It began like a rock being thrown into a pool of water. The faint echo from Sputnik causing a ripple in the imagination of humanity that maybe, someday, we could venture again as explorers into the depths of space. Less than a decade later, Resources and technologies were created and mustered to a massive effort towards achieving the clearly defined goal of “putting a man on the moon and returning him safely to Earth.”

Even in the cold war, where supremacy was measured, in the public’s eye in terms of weaponry, was the most heavily guarded secret how to build an H-bomb? Was it encryption technology? How about the control valves making the Saturn V rocket engine? History has finally rendered its judgment that the methodology of managing the lunar landing project was the most sought after, and most heavily guarded secret. Technology could be invented, systems could be built and tested, people could be managed and hired, but without a clear depiction of all the interrelationships in the incredible undertaking, we would never have made the journey. There would have been no way of even quantifying the cost to the “Ways and Means Committee” to fund the effort.

What is it, though, that makes this so compelling to us? Is it the pride in Apollo program? Is it respect for the people who made it all work? Perhaps it’s the awesome realization that we can achieve amazing feats when complex organizations are properly managed? Or maybe it’s a dream that, if we use the same methodologies, we can achieve anything we set out to do. But, market reality may be far too cruel to let us realize that dream.

It’s Not Rocket Science

Prior to the development of PERT or GANTT and systems to correlate the massive amounts of data required to support techniques of that sort, many managers used the philosophy of “If you need it done sooner, get more resources.” Certainly the pharaohs of ancient Egypt recognized this approach. More people move more bricks faster. While the Apollo program required large amounts of resources – money, people, time – it also required communication. People needed to have a clear understanding of who needed to know what when so that stages of the project could be completed, approved, and resources moved to other scheduled tasks. These are all of critical importance in today’s high resource turnover market as well. Why then, to metaphorically drop the bomb, do projects today fail with virtual certainty? Apollo certainly didn’t. The methodologies used for that project clearly achieved the objective. If it worked for such a complex project, why not for the vastly simplistic, in comparison anyway, software development life-cycle?

What is often missed, partly because this was considered classified until only recently, is that the methodologies used to run the Apollo project where designed as part of the Apollo project. The methodologies used were not designed with any intent other than to see the very clearly defined, and immutable goal delivered. Period. Arguably, the elegance of the goal statement, in its clarity, its immutability, and its achievability, were part of the key reason the whole project succeeded. Had President Kennedy said, “I’m going to create a company to develop a reusable launch vehicle to allow us to perform space exploration and mining, ” we would probably have never made it. That goal would have been subject to priority changes, budget shifts, and market realignment of what resources were in demand.

The methodologies used were not designed with any intent other than to see the very clearly defined, and immutable goal delivered.

The projects we run today, as project managers, are trivial in comparison to the Apollo project. While not impressive by today’s standards, entire IBM systems were dedicated to running the project management software operating on, literally, millions of separate tasks over an eight year timeframe. Today, we can represent typical application development in under ten thousand distinct tasks over eighteen to twenty four month timeframes. So why do we fail with such predictably? It certainly isn’t in the methodology. We have operations research people continually refining and validating it. It’s not in the technology; that has been pretty well at a sufficiently robust, comprehensible, and usable level for thirty years. It’s not in the management support; we’ve been training managers in the business, methodologies, and technologies of management for thousands of years. And, it’s certainly not in our ability to deliver new impressive technology to solve problems and needs, as is evidenced by what went into the composition and distribution of this document on a laptop computer, via e-mail, over the Internet. The reason lies in the definition of the goal.

The Goal is the Thing

We have clear evidence, throughout history, that clearly defined goals, including “Within a decade, to landing a man on the moon, and return him safely” can be achieved. Building cathedrals and pyramids were also complex undertakings for their time, but those also had clearly defined and immutable goals. Therein lies the beauty and purpose of the project management methodologies we are using. If the goal cannot change, the project can be accomplished.

And that is the problem. The projects we try to run have goals that, by their very nature do change. We cannot easily distill a simple immutable goal out of a client’s need for an application that solves a whole list of requirements; particularly when we know that that list will change. What then becomes the goal? Delivering the set of requirements?

Why Do We Have Requirements Documents?

There are two key and related reasons for using the requirements documents: clear specification and recapturing glory. While the former is obvious, the latter should not be discounted. Coming up with clear specifications and requirements allows us to put together our project plans. This defines the work to be done. In a sense, satisfying the requirements becomes the project goal. What we also try to do is to get the client to commit that the requirements will not change. We do this in an attempt to lock down the project and make it attainable; to make it possible to succeed. At a very primal level, we are also attempting to recapture the glory of the massive successes of the past. We feel the emotional need to have major projects succeed, and feel wonderful if they do; and feel dejected when they don’t. The problem is that we are virtually guaranteed that the projects we undertake will fail, despite our best efforts at managing them.

What Are We to Do?

Assuming that the user requirements as a whole do change, will change, and probably have in the time it’s taken you to read this paper, how can we possibly succeed? We need to learn from history. Apollo succeeded because it had an immutable, attainable goal, and people with the will to make it happen. There is no doubt that we, as developers, have the will. We usually also have attainable goals – although, always beware of problems that are not computable. So, simply put, go for the immutable goals. We can look at this from a broad outlook or a detailed one.

In a broad outlook, we can emulate President Kennedy and state a clear, large, goal. But, what did he really say? Did he say that you must use a big giant rocket to get there? Did he say that a space plane was the preferred solution? Did he care? No. He stated his goal and let the technologists arrive at the solution, by any means, and with any outcome, as long as it achieved the goal. He couldn’t have cared whether the thing was painted red, white, or blue. This is a very Machiavellian view: the end justifies the means.

In a detailed view, we can focus in on the details of each individual need and look at them as goals unto themselves. Satisfying each business function becomes a primary goal. Success, then, is measured on the effective delivery of each function, within the framework of an overall system. This is a very different view and may require new methodologies or a different application of current methodologies. In this particular view, the means is an end unto itself, because we don’t know where the end is anyway. This is not to say that there isn’t an overall goal; on the contrary, the overall goal does exist – it just is likely to move with little or no advance notice.

What Can We Learn and Apply from Apollo?

While the end objective of Apollo was very clear, the path taken to get there was scarcely definable when the project was started. The space program had two independent lines of development, each of which might have delivered on the vision: the space plane; and the rocket. Both lines of research were pursued independently; had significant merit; and generated significant long-term results. However, when it became clear to the planners that the space plane program would not be able to boost sufficient payloads into orbit, without radical new materials and technologies, that line of research was suspended – not dropped permanently, but only suspended. The rocket program was assessed as being more capable of scaling up to carry the fuel, supplies, and landing vehicle required to make the program a success. The space plane did not die, however. The research from that program was preserved and eventually resurrected in the space shuttle and hyper-shuttle programs.

But even Apollo was not a simple one-time delivery of a milestone. The harsh realities of systems testing did not allow for errors. So the entire program was subdivided into (and forgive the pun) launches. Each phase of the program: Mercury; Gemini; and Apollo, and each rocket in each the program built on the prior successes. Even the tragic losses, when things went horribly wrong, improved the subsequent launch. The Laws of Physics can provide rather harsh user acceptance test conditions at times. The planners made a deliberate decision to build on prior successes and failures rather than go for the big win in one massive attempt. There almost certainly exists a methodology that would have allowed Apollo to proceed with only one launch, with all the tests done on all components on Earth. Yet, the wisdom to perform repeated tests in ever increasingly stressful and changing conditions, both for the machinery and humans, prevailed and the project succeeded. Contributing to those changes were new developments in rocketry, computer technology, and materials science made as part of the project and independently. The program took advantage of these advances because it would help them achieve their goal because it would have been foolish not to. The changes were incorporated and resulted in changes to the project plan. They did not, however, accept undo delay waiting on some new development “just on the horizon”; but they did “pack more in” as miniaturization achievements exceeded their expectations. They did manage to incorporate some quite dramatic changes, especially after problems, without having to “throw it all away and start again”. They were keenly aware that they did not have a monopoly of new ideas and technological advances. They searched for, watched out for and where appropriate incorporated changes as the result of other advances in science and technology. They maintained an attitude of open mindedness and vigil awareness of what we going on around them to drive relentlessly onward to their goal. The Apollo program was successfully managed in a changing world just as we need to do today.

NASA became the product management agency, moving space exploration forward where it could, but operating in the commercial and military communities as an agent of Change.

Apollo was not envisioned as anything more than getting a man to the Moon. But once the goal was achieved, what next? Was it enough to send people to the Moon to muster the imagination of the World, to make footprints, and to collect rocks? There was no clearly defined follow-up objective. And this left NASA in a rather large conundrum. What would they do with all of their resources and infrastructure? On what basis will they be funded? Massive layoffs and changes in policies occurred almost overnight. NASA started looking for other things to do and other ways to do them. Very rapidly, it became obvious that NASA’s role in space exploration would have to evolve. We find today that NASA acts as a product management agency, moving the exploration of space forward where it can, based on its own strategic plan, but operating in the commercial and military communities to co-ordinate deliverables and act as a agent of and repository for Change. The parallels in this area to what happens in business should not come as a great surprise, but often does.

In the business of project management the ending of a project means many things to many people: a redeployment or freeing up of resources; rewards and punishments doled out, without seeming regard for who achieved their own objectives; reorganizations; lack of follow-on direction or vision. Many companies of“solve” this by undergoing periodic reorganizations tied roughly to budget periods so that no one actually has to experience the pain or confusion of the end of a project. They become wrapped up in the pain and confusion of the reorganization – but at least it’s an expected and politically understood pain. Some companies have taken the approach of funding based on annual budgets rather than project budgets. This puts them in a position of having to look for work after a project is done. And others, like NASA, are starting to take the approach of the infinite plan. They understand that they are in business for the long haul and that the future is uncertain. Their approach to projects is to down-size the projects and fit them into a larger strategic framework. When the strategy changes, the projects can still be completed or abandoned, without causing undue hardship to the organization.

What Does It Mean to You?

This all means that, if you are in the process of commissioning a large project, either in the role of a user or technologist, don’t get involved in the microscopic details of what it is going to look like. Concentrate on achieving the business objectives and don’t worry about what it looks like. Try to mentor your staff into understanding that the business objectives are more important than what technology is used to satisfy it.

It also means that, if you are engaged in a project, that you must quantify satisfying each individual capability as itself a goal. You must accept that goals may be added, cancelled, or reordered at any time.

The most challenging and visionary task is to recognize the immutable in a sea of change.

Fitting this approach to any standard project planning methodology is not the biggest challenge you will have. It should work in any of them. The most difficult task is to recognize the immutable in a sea of change. It is also where the challenge of being visionary and forward thinking comes into running a business.

• Avoid the temptation to pick “milestones” as goals. These are not goals; rather, they are events and triggers to other processes.
• Avoid the temptation to scope your goal too small. You may get caught up in building a giant user interface with thousands of individual screens. The temptation to think of each screen as being unchangeable and “signed off in blood” is great. These are not immutable either. Of course, having tens of thousands of immutable goals is probably not practical either.
• Avoid the temptation to scope your goal too big. Your goal must be attainable or it is meaningless.
• Remember that you are in business to delivery very specific products to your clients. Focus on that business. It may be a wonderful idea to build the next wave graphical operating system, but if you’re doing it for a trucking company, there is little point.
• Assess the methodology at every moment. Are you being most effective doing things according to the methodology? As we found with Apollo, the methodology is defined by what we are doing. When the methodology is no longer applicable, change it. It isn’t immutable, is it?
• As a user, you know that your signoff isn’t a statement of immutability on your part. If the business climate changes, you must move with it. You always have, haven’t you? As a technologist, understand this too – the signoff is just a statement that the requirements were acceptable at a given point in time or in a given business climate. Any specification document is subject to change without notice, usually before the toner has cooled down or laser has turned off from burning the CD-ROM.
• What you can do, if things get too confused, is think of goals as functional capabilities. You could, if you find it useful, consider that the capability itself is immutable. If it changes, declare the old capability dead, and declare the new one immutable. True, this may cause you to reassess how you did things the first time – is there a problem in that? Doing things this way, though, constrains you to have capabilities that are relatively independent.
• Do try to define your goals as being independent of other goals. What happens if your immutable goal depends on another immutable goal that was cancelled? Yours’ is too. So, you should immediately learn, that goals that are dependent on other goals are not themselves immutable.
• Do watch for things to become immutable. As in the case of dependent goals, once a goal is delivered, you can build upon it and declare your goal to be immutable. Remember, of course, that that does not mean that your goal may not be cancelled.
• Build on prior successes and failures. Learn from what does and what doesn’t work. Remember that a failure or cancellation of one line of development may not mean its permanent end.

As this synthesis of goals builds up, you will find a natural progression into the realm of projects structured around a product model. Deliveries of groups of relatively independent capabilities on a schedule convenient to clients end up defining releases. And this is why we’re in business.

What the Developer Expects of the User

Developers expect that the user is able to communicate their needs clearly, correctly, and completely. All too often, a specification boils down to “make it work the way I want it to”. Users have the responsibility to clearly communicate the objectives and the business needs – the immutable goals. Users are the primary mover of change, since they are the ultimate providers of services. Their expectations are at least influenced, if not driven, by external sources beyond their control. Clear lines of communication must be in place so that these goals can be continually reassessed and rescheduled based on business need.

Clear lines of communication must be in place so that the delivery of committed changes are in sync with commitment to accept those changes.

Developers have a strong desire to have their work accepted as soon as possible. Unfortunately, recent studies are pointing to opinions that users are unable or unwilling to move with change as quickly as technologists can deliver it. This has the dangerous problem of leading to a “why bother” attitude. Users must be in a position to understand what will be delivered when, and what processes of theirs will be impacted. Clear lines of communication must be in place so that the delivery of committed changes are in sync with the commitment to accept those changes.

What the User Expects of the Developer

Other than the impossible of knowing exactly what is needed when it is needed and proactively starting work on it years in advance – a clearly unattainable goal – users expect developers to deliver to them capabilities to do business on a committed schedule. Users do not care how developers choose to budget or plan or managed their projects or releases, as long as the capabilities can be delivered in a usable, deployable form.

Users expect to be informed of successes and potential failures in meeting commitments as early as possible so that they have the information to adapt their strategic plans. Part of their strategic planning process should take into account the scenarios of development not being able to deliver specific capabilities at a specific time.

Users also expect development to be able to change the order in which things are delivered. This is one of the most often missed parts of project management. In the course of running a business, situations arise, external to the business, requiring the order in which capabilities are delivered to be changed. Highly interwoven long-term and complex project plans, with single signoffs on the entirety, are usually (in the 98% range) unable to cope.

What is Expected By Senior Management

You are expected to watch out for the company’s interests. Try to organize your efforts into quantifiable goals which are immutable on their own, but changeable within the overall project context. Understand that the proverbial rug can be pulled out from under you at any time on a given goal. It’s much less painful to have that happen on a single business function taking four to six weeks to implement as compared with a twenty four month effort. Unless you are really fortunate to be working with a free hand to build something, you will not likely be given a goal as clear and as unchanging as “Hit Jupiter with a Rock”. Measure success in terms of the profitable delivery of capabilities rather than tracking closely to a project plan’s milestones. Ask yourself this question: which is more important senior management: tracking and delivering exactly to a project plan and exactly to a specification; or delivering what the market really needs and doing it profitably?

---

Randall Becker is CEO of Nexbridge Inc., a company specializing in product management consulting and change mentoring to the high-tech community. In a previous article, Taking Back What Is Ours, discussed back-sourcing, and appeared in CIO Canada in the December 1999 issue.