The project order is probably a regularly underestimated document in the daily project business. This may be partly due to the fact that this document is created when there is no real project yet. Wrongly so – in addition to the formal assignment to the project manager, it contains the proverbial core of the project pudding right from the start.
„A project is a one-time, goal-oriented undertaking under time, resource and quality constraints“ says one of the numerous definitions. By its very nature, this contains a lot of what will make the project manager and his team lose sleep over the course of a project. But how does an organization get from an idea or a need to the definition of goals and objectives? That’s right, via the project brief.
KISS
The shortest conceivable project assignment names the project „go shopping“ and the project manager „husband.“ However, as many a wife will know from her own painful experience, this is not always enough to ensure the success of this project. Regardless of whether the husband has already performed this task, it very often makes sense to give him a few more specifications, including:
- Client … „The wife, and thus it is clear that snacks and beer are not enough for weekend shopping.“
- Project start and end … „Leave now, and be back here this afternoon.“
- Business needs and goals … „You don’t need to know what we need, I’ll tell you.“
- Project deliverables … „Goods should be paid for, driven home, and stowed in the correct cabinets (yes, refrigerators too).“
- Project budget .. (self-explanatory)
- Project manager, possibly project team … „Please take the kids with you, they know where things are. And please bring them back with you.“
- Assumptions and restrictions … „Please move only downtown. If you don’t have margarine, bring olive oil.“
- Resource allocation … „Take the car, but you can leave the trailer here.“
- Appointment requirements … „Be at the butcher’s by noon because it’s closed after that. Frozen goods please buy no more than 30 minutes before you return.“
Theoretically, it is also possible to formulate this project order exclusively verbally. In daily life, however, it has proven useful not to leave it at that. This has many advantages for the project process, especially with regard to the start (clear and common understanding of the task), the execution („When does the butcher close again?“) and the acceptance („Thank you. And now please pick up the children from the supermarket again.“).
Some project managers also document the project processes (such as communication channels) in the project order, and that is certainly not wrong. Personally, I am more of the opinion to record the formal assignment and its framework in the assignment, and the process model (changes, communication, ..) in the Project Management Plan. This helps to keep the overview and clearly distinguishes both documents.
Goals ahead!
One more word about the goals of a project. Very often people talk about SMART goals, which are supposed to make sure that you don’t sneak around a poorly defined focus in the project. This makes perfect sense, but it has a drawback.
If one aspect of the project scope is not clearly schedulable (or even more popular problem: measurable), you already get into explanation trouble with the project order. So SMART is like all catchy concepts: they don’t work in every conceivable situation. So before you drive stakeholders, team and sponsor crazy with demands for measurable goals, because they rather have non-functional goals like simplicity or best practice implementation in mind, turn a blind eye.
If all goals meet the SMART criteria, that’s very good. However, if individual goals fall outside of this grid, discuss them in detail and write the assumptions and framework conditions into the goal definition. The more precise you are, the more misunderstandings you will avoid afterwards.
Write and shine
So you hear about there being a problem somewhere. In the simplest case, this can be just an idea that an influential, potential future sponsor expresses to you. When it becomes more concrete here, you should take action.
Determine who can contribute to this idea and who would be affected by its implementation. Once you and your sponsor-in-spe have identified all stakeholders, make the rounds and record requirements (ideally tracked in an appropriate requirements matrix). This phase is very important to both get the idea out there (and some sense of community) and to get different perspectives on the issue. From the requirements you then build a rough target model, where you should make sure that the project is big enough to make a difference, but not so big that it becomes unmanageable. In the SAP environment, a core runtime of between 6 months and 2 years has proven successful. If your project is much larger, think about portioning it, for example in the form of a program.
Coordinate the goals with the sponsor and your stakeholders to ensure that everyone has the same understanding. Then go into planning, define the specific project scope, the project organization required for this, the time schedule and the expected costs. Then go back to coordination and make sure everything is well understood. Work with the well-meaning stakeholders in the first (constructive) part, and then, when the document has a hand and foot, face the skeptics. Valuable input often comes from the latter on issues that you’ll encounter sooner or later anyway – so sooner is better.
The life cycles
Everything in the brief, and everyone in agreement with the direction of travel? Then follow up with a final meeting with the sponsor, and the document can be officially approved. Communicate the final document version to all stakeholders. Also, file the document centrally so the team can access it at any time.
Post elementary project order components (rough goal matrix, schedule, project organization chart) in their most current version in the project rooms. Hold a kickoff meeting where you essentially explain the mission to the project team and answer questions. It has also proven effective to use your regular jour fixe from time to time to refresh the assignment content in their minds.
When you send out a newsletter, always make the reference to the order. Recipients are not usually hanging out on the project, and in fact need to be reminded what it was about again right away with each communication. The occasional glance at the order is also helpful for conversations with the sponsor. All this is to prevent that in the course of the project the originally clearly defined goal is forgotten by some of the participants.
The end
If you have done everything right so far, you have a clear idea of the client’s expectations, and the team, stakeholders, and sponsor have not forgotten them over the course of the project. Towards the end of the project, the project brief then serves as the final landmark. Have all requirements been met? What about the achievement of objectives? Have the requirements been met in terms of time, quality and resources?
The project completion date and the final sponsor meeting should address these questions in order to establish a common perception of the project’s success at the end. Lessons learned sessions also deal with the contents of the project assignment, among other things, if these were perceived as not clear, or not clearly communicated. Listen, and learn from it for next time.
Good luck with that,
