Home | Login | Recent Changes | Search | All Pages | Help

StartingRightArticleCurrentDraft

Purpose alignment

The most fulfilling projects with which I have been associated had a significant purpose that fit my aspirations. I gained valuable experience. My work contributed to the successful conclusion of the project. The successful conclusion delivered significant benefit to the company. That significant benefit magnified the experience I gained on the project.

When more people on a project have aspirations in alignment with the project purpose, the project will be more fulfilling for its team members and it will be more successful.

The purpose of a project, along with its significance to its sponsor, must be clearly stated. Discussion about it must be allowed, even cultivated so that all can build their understanding of what that significant purpose is.

Internal goals (or those internal things on a project which must be attained in order for that project to successfully meet its purpose) are visible. These, too, must be open for discussion and even change, but not subversion.

People are free to work on projects of their choosing.

As I enter into a project or any piece of work, I try to understand its purpose, which is its externally visible reason why it exists.

And I enter a project with goals, what I want to gain from doing the work.

I find that the most fulfilling projects are those: - that have a significant purpose - where my goals and the project's purpose are most in alignment.

My behavior on a project instantiates my purpose on that project. It is what others on a project can use to understand better what my goals might be

purpose is visible to outside world - both through behavior and explicit statement of such.

I am one of many people who contribute to a project. Each of these other people also has goals and might also seek alignment of their goals with the project's purpose.

Projects can also act like people - they, too, have internal goals, which are visible and meaningful to the people of the project, and probably not to anyone else.

A goal is internal and is one of the things that thing that it is internal to wants to have happen.

internal needs vs external behavior: internal goals vs external purpose

heirarchy of organisms: companies contain operational divisions contain programs contain projects contain people

each of these serve a purpose (maybe many?) and have goals.

Goals drive behavior; behavior creates purpose. (forward chaining vs backward chaining behavior and decision making)

goals are internal; purpose fits into and aspires to improve a context

purposes are controllable; goals are not.

If you ensure the:

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

have specific definitions, you will create an environment in which people can align their aspirations with the project�s purpose alignment.

How to?

House 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 the 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 inspires 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 up 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, figure out how they depend on and 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 of 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 when is in their way. 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. Together you can assess that action against the purpose and significance of the project. These discussions are a mechanism 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 that vision was no longer relevant.

Maintaining a Meaningful Environment

When you do not see these benefits, ask yourself these questions:

Do I understand the project purpose and its significance against 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 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 you answer no 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, re-commission the project so that these parts are well understood and will not be forgotten.

If you have trouble answering these questions, wander around and 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

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