Tell me if you have ever experienced this scenario:
A customer comes to you with a need. This creates a project to complete the task and typically can take the form of a design build project. One may hear "design build" and think some sort of contracting trade, but I would argue that the design build scenario is not unique to contracting.
Design build considers the needs of the client, with the knowledge of the vendor, to ultimately create the end result after terms are agreed upon by both parties. The design or development process can be iterative or completed all before the project commences. During this requirement gathering period and during scope development a unique relationship begins and is formed between both parties. Hopefully this process is positive and a certain level of trust is mutually earned.
This is where the cart starts to move ahead of the horse. Both parties are excited about the project, and both are anxious to start work. The main question to ask yourself is, have you both truly agreed on everything up front? You have probably gathered the needed requirements to design the portion that will be completed first. You have probably agreed on a pricing estimate and developed a contractual agreement to protect both parties legally. You have probably even developed some sort of schedule as this may be a determining factor for whether or not the client wants to take on the project or if you have capacity to do so in the time frame they are looking for.
Does it sound like everything is set for the project to begin? Typically, outside of construction, there is not a true "groundbreaking" signifying the beginning of a project. It slowly begins with small portions, phone calls, emails, a little back-end work on a few items, and before you know it you are fully emerged in the project. At this point, if this has happened, your cart is WAY ahead of your horse.
Who is the project going to affect? Are you just thinking of the Owner or Owner's rep, or also considering any party from outside or inside both organizations? What are they looking to gain or get from the completion of this project? What communication is important to them? How do they want that communication, how often, and it what format? Do any other projects rely on this project? These are a few simple questions (not intended to be an all-inclusive list) to help you realize you are missing two key ingredients, and ultimately, and the most important detail, an agreed upon project management plan that both you and the client agree to.
To define who the project will touch and how it will affect them produces two things. First it produces a stakeholder list or registry, but more importantly a stakeholder analysis that will flush out the needs you will have to consider during the completion of the project. Simply producing an end result of a good or deliverable will satisfy the most basic element of the engagement. What you still could be left with are needs of additional stakeholders that have not been met.
Developing this analysis will also help develop another key component, the communication plan. "Knowledge is power" - does that sound familiar? Remember that each person affected by this project has specific interests that will need to be addressed. Maybe one of the investors will need specific schedule or resourcing information at a regular interval to inform the loaning entity of specific details. This could affect future funding for the rest of the project. What if the program manager within your organization needs to aggregate project information from within his or her program for reporting to the executive board.
Both of these instances require different information to be ascertained through not only different methods, but perhaps different mediums and frequencies. Do you have 100-200 stakeholders? Is it realistic to disseminate information amongst them through email, or is the development of an FTP site more conducive to time management?
Let's now look, if we assume we have answered all the above questions and provided a plan to address them all, at what we have developed. We have a stakeholder registry and analysis, requirements, scope development, resourcing plan, project schedule, contractual agreements, and communication plan. These are the key ingredients of the overall project plan (less the risk analysis which could be discovered during the stakeholder analysis or requirements gathering and scope development). Each of these separate pieces should then be formalized and put together in a logical order and presented as such. This will be the plan used to complete the PROJECT that produces the PRODUCT.
Notice the last line...that is an important consideration. A project creates or produces a product. A project are the steps taken to produce a final result. The project plan is the detailed written document that outlines how it will be done. Once completed, it is presented to the client and each side then agrees to it. It is much like a contract, and can hold the same legal significance. However, most of the time it is an amendable plan that sets forth criteria for future issues that may arise, and the contractual obligations typically lend themselves to more typical items such as cost related items, schedule and completion date, privacy issues, and governmental considerations.
Hopefully this scenario description has caused thought provocation around your project implementation standards. Remember that keeping the horse ahead of the cart makes it much easier to steer as you gain speed.
Chris Thompson PMP, SSYB
No comments:
Post a Comment