One of the fundamental questions project managers face with each new project is how much detail is required in the project plans. With the use of project planning tools, the tools will support any level of detail so the question becomes a decision for the project manager. There are several factors in which the project manager should take into account when constructing a project plan including 1) implementation model, 2) approach for monitoring and tracking budget and schedule (EVM), 3) project risks identified at project outset, 4) experience of the project team, and 5) team composition including the number of independent organizations working on the project.
Implementation Model
The decision on the implementation model is an important one as each model category has its own set of deliverables and mechanisms for managing scope, testing, etc. If we separate the models in three categories; 1) waterfall, 2) agile including scrum, kanban, etc, 3) iterative or evolutionary where scope is defined up front and the development broken down into iterations, we have different project planning needs associated with each.
In a waterfall model, the work breakdown structure (WBS) becomes more important as the project coordination is typically accomplished through this plan. It needs to be more detailed than the other models with tasks being a duration of 1 maybe 2 days. This level of detail affords the project manager the opportunity to track status daily and make adjustments. Many project managers will plan at a weekly level which only provides empirical data on a weekly basis as to the progress. More frequent updates are available via verbal reports but these tend to be more subjective than seeing working software or an interface exchanging data.
In an agile model, a traditional project plan may not even be used. I have several projects using agile practices and have not produced a project plan. With a sprint or iteration plan that establishes the timeline and functionality to be delivered in each, the effort in a traditional project plan seems overkill. Some customers have requested a very high level plan to define start and finish dates of sprints, inclusive dates for User Acceptance Testing (UAT) including planning, and even deployment activities culminating in a go-live date.
With iterative, it is a hybrid of waterfall and agile. By including waterfall like tasks such as a functional design or use case design at the outset of the project, it seems logical to define activities for these deliverables including the dates for customer approval of these scope documents. By including more formal deliverables as noted above, the coordination for these tends to come from the project plan. With this model, having a daily coordination/status standup meeting has worked well as it reduces the coordination risk inherent in using the project plan.
Budget and Schedule Monitoring Approach
In projects these days, there are two major areas of budget and schedule management. Many companies are more concerned with hours expended and a go-live date then tracking effort completion and the associated monetary impact. With the hours based approach, a traditional project plan including accurate durations and resource assignments becomes critical as it becomes the baseline from which to measure on-budget performance. This approach restricts the project managers options to reorganize or reassign work across the project team in order to manage budget. If hours are the only consideration, then all hours are viewed the same where as the reality is each resource has a different cost so the hours are not equal. For example, let's say we are observing a growing cost variance and determine 40 hours of work can be assigned to a resource at 2/3 the cost and the currently assigned resource. Assuming the work is completed in the same amount of time, the project manager has saved 1/3 the activity cost and reduced the negative cost variance. By only looking at hours, the only way to reduce a negative cost variance is to complete the work in less time than estimated. The project manager does not have any management options in which to work the variance.
The other major budget and schedule management mechanism is Earned Value Management (EVM). This technique was originally developed for major US Government programs to get early insight into cost or schedule performance thus enabling project managers the opportunity to make corrections. This technique requires project plans at levels of detailed at least as great as daily tasks. In order to effectively implement EVM, a project team needs a tool that integrates the timesheet system with the project plan so the completion of the timesheet becomes the status reporting against the project plan. Timesheets in this scenario should be completed daily so the project manager has more frequent updates on the cost and schedule performance of the team.
Having project plans at this level of detail takes a significant effort to produce initially and even more so to maintain during a project. Besides large government organizations, I am not aware of anyone currently using this method as the overhead is greater than most companies are willing to commit.
Project Risks
Project risk assessments at the outset of the project are one of the least used and most important deliverables/activities for the project manager. The tendency for many projects is to move directly into planning the technical activity, architecting the solution and building the interfaces. Although this seems prudent to get moving with the work, assessing where the risks are is a key driver into the implementation model best suited for the project, project team, and risk tolerance of the customer.
These risks can range from previous experience of the business users with an implementation model, level of confidence in the business users knowledge and vision of the future state, capabilities of the implementation team, and business impacts for schedule movement. As the project manager assesses risks such as those noted above, these will drive the level of detail in the plan since the relative detail in the plan can be a risk mitigation measure in itself. The number, type, and depth of project deliverables needed to appropriately manage risks drives the details of the project plan including potentialy separate tasks for deliverable completion, reviews, and approvals.
Project team experience
The experience of both the project and business teams can drive the level of depth in a project plan. With more experienced teams, they have a good feel for the rhythm of a project and the pace in which progress should be made. This level of experience can lend itself to project plans at a higher level since the team can fill in the details and as I have written previously enables senior experienced resources the flexibility to be creative and enjoy there professional lives to a much greater extent.
When assessing the team's experience, project managers should keep in mind the implementation models discussed previously in this post and which are realistic options for this project.
Team Composition
With many projects these days, there are many people involved and potentially from many different organizations within the companies or potentially many different companies if the project is outsourced. As the number of organizations involved increases, the complexity of coordination grows dramatically. The agile methodologies utilize the daily scrum or status calls to mitigate much of this coordination risk but should be considered only a part of the solution.
With multiple organizations and especially when these multiple organizations have goals and objectives that may not be 100% in alignment, the need for use of a project plan becomes more pronounced and this drives up the level of detail needed and focus on the plan. For example with a project that is outsourced, the vendor has priorities that include their company profitability, staffing considerations, and internal risks. These priorities are rarely 100% in alignment with a company using the vendor. The use of the project plan and increased depth in that plan provides a mechanism for reaching agreement where all parties have their unique priorities satisfied.The question of the necessary depth needed in project plan is subjective by nature and coupled with the implementation model is the biggest early decision a project manager will make. Once made, it is difficult to change the model so project managers are typically resigned to the model once defined. The level of depth can be high level for an agile based project or at great depth for a waterfall project using EVM for measuring cost and schedule performance. In my experience, projects tend to be planned and replanned as project managers react to the emerging situation on the ground and work through the multitude of issues that arise on a daily basis. My tendency is to plan at the highest appropriate level so my project time is spent in management activities like risk and issue management, resolving staffing issues, and assisting with technical or business changes instead of more administrative tasks of maintaining the project plan as this can also pull project resources off of producing tasks and onto planning tasks. This is a difficult question and one that requires forethought, comittment to the decision, and knowledge of the available options.
