four components. This is job number one for the project manager and technical lead (sometimes called the project architect).
Show the project team the significance of the project. Convince them that a successful outcome to the project impacts the organization's bottom line. Communicate this early and often to all members of the project team. Wrap them in the cocoon of your company's business model, then paint a picture for them of the beautiful butterfly that will emerge from this project. The specifically defined purpose and significance of the project can inspire the project team.
Next provide roots-the foundation from which they can begin to do their work-by connecting their work to the rest of the organization and by guiding them in how they will do that work. Connect them to the rest of the organization by making key people available early. Create a context diagram with them. A context diagram shows all the events accepted and generated by the deliverables of the project. Put it in the Project Charter. Base the requirements and analysis work on the context diagram.
Build a framework, no matter how sketchy initially, to guide the project team in how it will get its work done. Identify key deliverables, and figure out how they depend on and are separate from each other. Organize the project around these separate pieces and their dependencies. Remember that this work is artful; trust your experienced technical people.
Inside this framework, project team members create their own meaning. They discover their purpose, understand its significance (all the way up to the company's business model), see how it fits with the project work, and create their own framework for how they will accomplish their work.
The Benefits of a Meaningful Environment
When you start a project in a meaningful environment, you get many benefits:
- You can say why. Nobody has to tolerate meaningless explanations. No more of that "Just do it!" fluff.
- You can root your delivery dates in the surrounding meaning. You can point to something significant to the organization that this project supports. Project team members will easily recognize "Just do it by (some arbitrary date)!" as a management ruse to goad them into working harder, rather than smarter.
- You know when you are wasting your and your team's precious time. When users or business people are not available to the builders, you know immediately that the effort is not considered significant by the whole organization. You have the evidence you need to stop that work.
- You can contain scope. You can understand and communicate the essential pieces of what must be delivered; these are clear in a meaningful environment. You do not have to tolerate the addition of features that do not contribute to the purpose and significance of the project.
- You can trust project team members to get their work done. You can trust them to bring up issues responsibly. You can honor them with meaningful discussions about their work and issues that are rooted in the broader significance of the project.
- You can have meaningful discussions with involved team members about proposed actions. These discussions are mechanisms to further the shared understanding of the purpose and significance of the project. When you do this openly, you decrease the number of meetings and the number of people attending those meetings.
- You can communicate the inevitable changes when they happen. You have help in assessing their impact. And you allow people on project teams to adjust their meaning to fit the newly adjusted bigger picture. When you do not do this, you run the risk of double-crossing people working