Now, I want to know why. When I know why-and that why is compelling-I am more motivated and better able to apply what I know. When the people around me know why, I sense that they, too, are more effective. And when we share an understanding of a compelling why, we are much more effective together, as we have a basis for dialog and decision making. The work we are doing is meaningful to each of us.

When I was younger and less experienced, I worked on faith that the people for whom I worked knew why or that the idea was so noble that why would become obvious to everyone. I remember, perhaps fifteen years ago, working diligently to figure out how to apply an expert system somewhere, somehow, in our large corporation. I fought the good fight-A.I., which included expert systems, was to revolutionize how people worked with computers. I had been inspired by sales people and by my own management. "Go forth with this new magic technology," they said, "and save those poor corporate souls from themselves. They, too, will see the potential we see. They will willingly throw down the chains of how they work now and will embrace your solutions. They will be like so much putty in your hands!"

I was inspired and I did go forth. Apparently the chains of how they worked were stronger than the liberating potential they saw from my expert systems. Even though I had a deep understanding of what they did, I did not understand why they did it. I had an elegant, really cool solution. But I did not understand their problems or speak their language. I tried speaking louder by showing them more diagrams about how the magic happened. I wanted them to see the wonder of it all; if they only could see how wonderful it was, they would understand.

I failed, and I thought it was because I was unable to make them understand. Now that I am older, I realize that I failed because there was no way I could make them understand. My message was meaningless to them. I was a voice disconnected from their business realities. I couldn't understand what significance my magic could have had for them, much less discuss this with them.

Now, before I will commit to work on a project, I want to know why the work of that project is significant to the people who will be accepting that work. I want to be inspired when I understand how my new role will help create a significant result-greater than anything I could have hoped to do alone. When I find a meaningful environment surrounding me, I am free to create a meaning for myself, confident in the knowledge that I will be effectively working toward that larger significant result.

The Elements of a Meaningful Environment
If you sponsor, create, or lead projects, make them meaningful for the people who will be working on them. Ensure these four key components have specific definitions:

• project's purpose: why the project exists
• significance of that purpose: why the successful outcome to this project is important to the organization
• fit of that project's work into the organization: how it connects with the surrounding technical and organizational context
• framework for how the work of the project will be done: a first cut at the project's organization and its deliverables' conceptual design

Keep these definitions in a Project Charter (sometimes called a Statement of Work or something similar). The Project Charter will have other sections and, at a minimum, it must address these 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 on the project. Perhaps you have experienced the feeling of buying into a vision, working hard to bring that vision to life, only to find out that the vision was no longer relevant.

Maintaining a Meaningful Environment
The responsibility for maintaining a meaningful environment does not just fall on the shoulders of those who sponsor, create, or lead projects. Everyone on a project is responsible. When anyone does not see these benefits, we can ask these questions to gain an understanding of why:

• Do I understand the project's purpose and its significance in the context of the organization's business model?
• Have I done a good job of communicating these to the project team members?
• Have I acted to undermine the meaningful environment earlier established?
• Do I understand how this project and its deliverables fit into the organization?
• Have I communicated this fit?
• Do I understand the framework the project is using to get its work done?
• Have I communicated my support of this framework to the project team?

If "no" is the answer to any of these questions, it is time to renew the Project Charter publicly. Bring it out of mothballs, get everyone together, and figure out what parts of the charter people do not understand or have forgotten. Then recommission the project so that these parts are well understood and will not be forgotten.

If you have trouble answering these questions, talk to people working on the project. Ask them what they are working on and ask them if they understand why. Do not accept answers like "Because I was told to" or "Because it's in the project plan." If project team members cannot answer these simple questions, then you have another reason to renew the Project Charter.

The Payoff
I want to understand why I am being asked to do something. I want my fellow project team members, leaders, and sponsors to also understand and behave consistently with that why. When I do not see that, I want to feel free to ask why. When I can ask why and when I get straight answers, my respect for those who answer grows. And I feel respect from them because they trusted me enough to give me straight answers. The give and take in these frank discussions is the essence of creating a meaningful environment for projects.

Provide the raw materials for a meaningful environment: the project's purpose, its significance, its fit, and a framework for its work. Project team members will fashion a meaningful role for themselves that supports the broader meaning. They will believe in the project and will work smartly toward its successful outcome.