Today's Conversation with Kip covers my simple view of project management. It can be viewed as the simple lists of;
- What, or a Scope Diagram
- Who, an Org Chart
- When, a Timeline and How Much, a Budget
- What to do, or a list of issues and risks
Here is the overview video, Episode 239 of Conversations with Kip.
Project Scope
The first page of a project plan is most helpful if it describes what is being done. Note that my list doesn't include a page dedicated to "why" or what are the benefits of the project. They could be included as part of this, but hopefully the diagram of what is being done helps communicate quite clearly what those benefits are.
I have found on large projects it is useful if people can see the relationship between what they are to do on the project and this diagram, how they fit into the end result being created.
The clearer the boundaries of the diagram--that which is in scope from that which is out of scope--the more helpful it will be in keeping the project focused on the most important points.
The banner image of this blog post is one such graphic.
Here is Episode 240 of Conversations with Kip, describing the Project Diagram
Org Chart
The second page of the project plan is an Org Chart, the who of the project.
Projects are greatly affected by the skills of those involved. What one might accomplish with recently college graduates will be very different than if using 1st graders. Such differences in skills don't just come with age, but also come with life experiences, particularly in professional or trade development.
The Org Chart for large technical projects at times requires three types of roles:
- Technical Leadership Although at times not empowered with formal authority in some ways, this is the first of leadership on technical projects. If not empowered with formal authority, and also not clearly empowered with moral authority the project will be at risk in leadership. I often call these leaders the solution architect as the head, and the integration architects as the assistants.
- Delivery Managers Technical leadership at times does not have as strong a sense of people and deadlines, and thus at times might need to be supplemented or supported by Delivery Managers. These people often have very good technical skills, but are attached more directly to schedules, peoples capabilities, and consideration of compromises that might be needed in some cases to fit within resource constraints.
- Organizational Managers At times someone with formal organizational authority, the Organizational Manager, can perform the functions of the delivery manager as well. But if not, there must be someone who has formal authority for the sponsoring organization to allocate budgets, deploy resources, and other activities.
A good architect of a skyscraper takes responsibility for the building in its finished form. If technical leadership of the project does not take similar responsibility, which at times means they must pay attention to budgets, to people, schedules, and issues, then they are doing something less than leadership.
For smaller projects, all these roles can be filled by a single person. For larger projects, the greater these three individuals work as one--as Jeff Wolfers once said operating such that there is no daylight between them--the greater the chances for success on the project.
Here is Episode 241 of Conversation with Kip, Org Chart Overview.
Timeline and Budget
The timeline and budget are very dependent upon What is to be done and Who is to do it. It is possible to define things that cannot be done, and to attempt to do them with people who are incapable of doing them. No amount or time or budget practically will fix those issues.
Rick Roth taught me that an expert is judged by his or her ability to predict. The timeline and budget are where this expertise shows up quite frequently. Knowing what and deeply knowing the who is important in any prediction.
And taking responsibility for hitting such projections is a sign of confidence in them.
At times, having the right order of magnitude on the projections on a concluded project is a measure of success when all the possible variables are included.
This is Episode 242 of Conversation, on Timeline and Budget
Meeting and Ongoing List Management
The last elements are a description of how the project will work, and the most concrete why to describe that is a set of meetings to work a set of lists. There must be consistent meetings to discuss two types of lists, at a minimum; a list of issue and a list of risks.
Of course progress on meeting milestones should be tracked, and budgets and other things that can be measured. But one executive taught me that the measure of success on large projects is how fast decisions are made. The list of issues is a good source of seeing that progress.
I was taught in another instance to be careful of attempting to manage things that should be solved, or attempting to solve things that should be managed. Some things, at times called risks, cannot be solved completely. Attempting to solve something that cannot be completely solved gives a false sense of security for some period of time perhaps; at other times undermines the credibility of the leader as it is clear such an issue cannot be solved.
At other times, attempting to manage an issue that should simple be solved wastes time, and shows lack of courage or strength in the leader to deal with the issue that should be confronted, and solved.
It is not easy to know which issues should be solved, and which should be managed, but doing so is an important element of successful project leadership.
This is Episode 243 of Conversations with Kip on List Management
Here is the Playlist of all these videos in order.