The goals of a project are its requirements and constraints at the highest level. These goals need to be stated early and revisited constantly by everyone on the project. Why? Because people working in an organization often have conflicting individual goals. The salesman wants to maximize the gross revenue from his sales, since his commissions are based on revenue. The product manager wants to maximize the profitability of his line, so his boss will consider him successful. The engineer wants to get all the promised functionality into the next release because a bonus is riding on it. These goals do not align; they may even be in conflict. Organizations are big, messy things, and unless conflicts are made visible, they will not be addressed.
A project can’t be messy for too long or it will be rudderless. Up front, the goals need to be articulated, reviewed, and refined, so that there is a reasonable assurance that the various patrons and stakeholders have truly converged on an agreement for the expectations for the project. When a project is building a single system that straddles several city-states of organizational power, it may be no mean feat to find a single set of goals in a diverse community.
If the stakeholders can indeed find a set of nonconflicting goals, then these goals become the vision for the design and construction. However, even if the goals have been properly defined, they are of little use unless they remain visible. Without constant reminding of the overall target for the project, it is too easy for people to forget them and lose sight of the project’s main purpose.
Analysts and business people aren’t the only ones who need to keep track of the goals. Designers need to know the goals in order to make informed design choices, asking for example, “What is the expectation for the operational life of the system? If we run it three times over its life, we may want to design differently than if it will run all day, every business day, for at least the next decade.”
Just about every project is under time pressure, and as the project proceeds, it may become evident that not all features can make the first release. Which features make it into Release 1 is clearly based on decisions made by product and project management, and those decisions are anchored by the goals.
Having correct goals is crucial. Keeping everybody aware of these goals makes an enormous difference to the project and to the product it produces. Like Carolina, you need to give your goals a seat at the table.
"This war isn't going to blow anything up, only turn everything off."
Suzanne and James Robertson's "Requirements: The Masterclass LiveLessons-Traditional, Agile, Outsourcing". 15+ Hours of Video Instruction.
Take a look at Tom DeMarco's Risk Management for Dummies article, published in CrossTalk.
Als auf der Welt das Licht Ausging, the German edition of Tom DeMarco's science fiction epic, Andronescu's Paradox, has now been published by Hanser Verlag in Munich. Translation by Andreas Brandhorst.