This is a guide to help you start your project, using the articles on this site.
You may not be able to affect all of the decisions referenced in these articles, however, it is in your best interest that you know what decisions are being made. From that, you can better plan your actions, and give direction to your reports.
Some companies have a policy to start this work on project planning prior to actual kickoff, but frankly, I never found this that effective. The customer always had a few last minute changes, and the company organization and staff availability typically changed also. If the kickoff is delayed, there are likely key decisions that are yet to be made that will affect the project. I did not find planning without knowing these decisions very useful.
On the other hand, core technology development and tool training prior to award was very effective. I recommend spending your money on these activities prior to award. These were much less likely to change at the last minute, and had a lasting impact on execution.
Most projects are either:
internally funded, or
Funded by a contract for a customer.
The philosophy and methods for the two types of development are very different, especially in the initial phases, as shown below.
Some programs are partially internally funded, and partially customer funded. For instance, you are developing a new technical capability on company internal funding, and a customer is funding using this technology in a production product. In these cases, it is best to separate the two activities, and run them at two interdependent projects. This way the goals and objectives won't get blurred, and you will be cleaner from a financial perspective also.
Internal Development
Below is what you need to plan an internally developed project, in order of precedence:
Business Plan - To plan the job, you need to understand it's place in the business. Internal products do not get beyond the idea stage without a fairly complete business plan. Eventually, you have to make money on the activity, or show that you will. This knowledge should affect many of your decisions. Of course, if it is your concept, you will know this very well.
Review : How to Launch a Product - Why is this a good opportunity? Why was it green lighted? You need to understand the strengths and weaknesses of the product opportunity , so you can account for them to your planning and execution.
Review: Priorities - How to Determine and Execute to Them - even if you do not publish them, it is important to work to a model. It will allow you to be more decisive, and provide a framework to evaluate your trade-offs.
What is financial success on this job? The must be an analysis showing the return for the company. You cannot make decisions to achieve success without knowing what has been assumed. See your finance people if it is not handed to you outright.
Stakeholders - PMBoK has a pretty good write-up on this. Understand your stakeholders, to make sure your discussions are targeted properly.
Approach - Review How to Avoid Disaster. Take a step back. Make sure you aren't missing something. Do you need a brain storming session?
Resource Plan - A business plan usually makes significant specific assumptions about resources to be applied, especially for an internally developed product.
Meritocratic organizations will put the Approach as the highest priority, while the Colonial management style will put the Stakeholders as the highest priority.
On internal projects, the Product Manager may want to manage some of the above (for instance, Stakeholders), and leave the Project Manager to manage the rest. Recognize that this is common among Product Managers, and integrate them into your management plan. The Product Manager may not want to quantify or finalize their needs. If you hold off complete definition of the effort, the product could be anything, satisfy anyone. It will also never exist. This is a classical bone of contention between Product Managers and Project Managers. Go at it with eyes wide open.
Externally Funded - Design to Specification (Contract) Development
Externally funded activities are more straightforward management-wise. There are typically a collection of inputs that describe the work to be performed, and the performance to be achieved.
Be sure that you have established the order of precedence of your controlling documentation. There may be quite a collection, and conflicts are very common between inputs. When you find a conflict:
identify it concisely,
verify that your team has identified no technical or logistical way to resolve the conflict within scope - due diligence, and all that stuff,
state the precedence that will be used to move forward, and
Provide a date by which it must be resolved to maintain the published schedule.
Good customers will work to close these items as quickly as possible. Bad customers will often ignore these conflicts until the last minute. So tell them when the last minute is.
A typical order of precedence, most important first:
Negotiation Results/Minutes - There are always a few things that are tweaked at the end.
Statement of Work - Generally the statement of work takes precedence over the specification, but not always. Cost Plus/Fixed Fee, for instance.
Specification - see the article on Requirements if you need a refresher on the practical uses of a specification.
Formal Questions and Answers During Proposal Process
Proposal - make sure you know whether the proposal is obsolete, or has some contract weight.
All of the above needs to be folded into a concise set of working contract documents. Theoretically, you can work to the combination of the above sources - but this is a bad idea for all but the simplest of contracts. Integrating information from these inputs into a consistent statement of work is well understood and accepted as a general practice.
The customer may do this, and want to hold and control revisions on the masters. Make sure to request a baselined version of the reference documents based ONLY on the above criteria, as of the award date - before the customer starts making more changes. Or else your job will get messy fast.
This can be difficult as the customer works to "clean up" the specs, typically adding "clarification" that increases scope, or introduces conflicts with existing requirements.
Generation of a new Specification or Statement of Work may be required as part of the contract. In this case your company will be tasked with generating and controlling the detailed specifications. These will then be provided to the customer for review and comment at regular intervals. The task remains the same. Each of the contract documents has an owner, and the opposite party has review and acceptance authority.
Be wary of Technical Working Groups. In this case, "we all" develop the material, "we all" agree, using a legislative process. This method is very slow and results are unpredictable, sometimes terrible. It is better to have a single authority responsible for a integrating all the material, and others review the result to provide comments with justification, for disposition.
Sometimes the Spec and SoW are very general, and were only generated to allow bidders to propose what they believe to be the best approach. They were intended to become obsolete upon award. The accepted proposal becomes the controlling document. This is typical for municipalities and commercial facility upgrades. In this case, your Proposal and Q&A take precedence. You are held to these, as your offer, and the effectivity of the request for proposal expires at award. Your proposal is what you are required to do.
In any event, get your sources and precedences straightened out ASAP. It's dirty work, but worth it in the long run.
You must also determine whether the development is to be Parallel or Serial. Requirements documents and planning are radically different for the two approaches. If you don't know whether a development is parallel or serial, you cannot plan the job successfully. On a larger job, some parts may be serial, some parallel. You may manage a serial internal development, combined with a parallel contract development, or vice versa. Make sure you figure out what parts must be serial, and what can be parallel.
This will typically be dictated by your corporate structure and tightly integrated with your EVM and Finance departments. If you do not have a standard WBS, the PMBoK WBS method is a good place to start. You will need to have at least a primitive WBS to place the estimates where they belong to generate a summary for review.
The WBS is critical for establishing metrics to allow for estimation, and to provide backup for fact finding.
You will almost certainly have to re-estimate the job upon award, even if the customer is accepting your proposal. There are always last minute changes, and options to be combined. Negotiation changes will have to be inserted, a reserve defined and other considerations must be incorporated. In my career I have encountered two contracts that were awarded over FOUR YEARS after we submitted a proposal. The proposal can be a basis of the estimate, but even if a good WBS was used to bid the job, you will have to straighten it up.
Below are the pages that will help you with this:
How Many Prototypes Do We Need?
I recommend using a website for publishing the status, and making the appropriate documents available to everyone. These communication methods should be decided upon and published at the kickoff meeting. If you don't do this, people will certainly end up working to the wrong documents, causing all sorts of problems. Sharepoint is a tool for this, but certainly not the only one.
Pages that will help you with this:
Web Methods and Project Management
An important part of communication is working with in process documents and changes. Design your site to communicate clearly whether a change is in, or not.
Set these up as soon as possible. Once they get into the system, they are the devil to change. Be advised that you probably do not get to pick any of these, and the people who do decide these things take it VERY seriously. Don't step on someone's toes the first day.
No one expects a detailed schedule on the first day of the job. Instead do a bullet list of the critical milestones, and tell the people that you will be coming to see them to go over the actual schedule. Even if you have a fairly detailed schedule to back it up, stick with the high level dates to get feedback. It will make you seem like a nicer person.
Schedule important? Here is how to improve it: Schedule Emphasis
Even in mature companies, this subject may be a matter of some uncertainty. Prior to the kickoff, fill in this chart and publish as much as you can at kickoff.
PM/PE/System - Roles and Responsibilities
I have been to kickoff meetings held immediately after award, but these were pretty ceremonial. Since many things can change at the last minute, many of the products to support kickoff (identified below) don't exist. The items below are essential to have in place, at least conceptually, before the marching army is turned loose on your project.
So take a few days at least, to get together enough info to make the kickoff more than ceremonial.
For a Parallel development, the kickoff must be with all players. As a matter of fact, there is probably stuff they need to bring to the kickoff. Don't hesitate to task them with providing material for the kickoff to present themselves.
For Serial developments, kickoff is a completely different animal. The initial review is not as important - in fact, you may not even know who the contributors will be in the later stages. What you do instead is introduce each player at a separate review as they become involved. The kickoff is primarily to show the stakeholders you understand the problem, and have a plan for execution. The first function in the serial design path may get value by attending, but even this is optional.
Review this article to determine which method you will be using: Parallel vs Serial Development.
If you are using web methods, you still want to keep a record. An example of a kickoff sheet to present and mark up during the review is attached below.