Project planning, execution, monitoring, and control techniques on large complex programs

 

Introduction

Why do many large IT programs struggle to meet critical milestones and business objectives? Larger programs necessitate more complex contracts that in turn necessitate more robust change control and scope management procedures. In addition, financial management becomes more important as the program size increases and becomes more visible to senior management. Also, as programs increase in size and complexity, the number of stakeholders and communication channels increases. Program failure can typically be traced to poorly defined program management processes and the absence of an integrated master schedule that appropriately mitigates for the risks associated with larger program size. Project plan construction, maintenance, and dashboards that accurately reflect status are critical to the success of these large programs. This can only be accomplished with disciplined processes that permeate throughout the program organization, supported by a program culture that aligns with the strategic goals of the program.

Project plan construction is more than opening a project plan and typing tasks that need to be completed to get the job done. It requires thoughtful activity definition, sequencing, and resource estimating and their direct integration with the program's detailed development life cycle. The key here is that the program's development life cycle steps that become the basis for creating program estimating templates and models that eventually make up the detailed tasks and activities in the project plan. The estimating of these separate work-streams usually is done by different organizations. Developing and using standard estimating models and templates aligned to the program's development life cycle is critical and one of the first steps in successfully building a plan that can provide true status of progress.

Although construction of large program plans are important to defining how the work gets performed and when it will be completed, updating and maintaining the plan properly are just as critical. There are many opinions as to how a large program plan can be maintained, but one fact is obvious, it requires a disciplined management processes for maintenance and change control. For large IT programs to be successful, it is critical that disciplined maintenance and status processes are mandatory and that they are supported by senior leadership. Finally, these disciplined processes used for maintaining accurate progress of large plans provide a wealth of information that feed into overall program metrics reporting for monitoring the health of the program. The reports or dashboard become the mechanism for which the program can identify issues quickly and act on them before a major failure occurs.

The following sections of this document will review four major phases of project planning that, if executed with rigor and discipline, will reduce the risk of program failure.

- Develop the Planning Approach and Strategy

- Build the Plan

- Communicate the Plan

- Execute, Monitor, and Control the Plan

Developing the Planning Approach and Strategy

Developing a planning approach and strategy includes two very key components; guiding principles for planning and gaining concurrence on the approach from your client. Guiding principles need to address specifics as to how your program is structured and how it will provide status. Many programs either fail to define their program's project plan at a level that is appropriate for reporting status or they have too much detail, which becomes too difficult to maintain. Your approach and strategy should consider some basic concepts, which will help drive the plan construction:

- Mapping the high level structure to either a client provided WBS or contract WBS

- Sequencing activities and their dependencies as if building a roadmap

- Elaborating the WBS to map to the life cycle methodology (e.g., design, development, deployment)

- Determining the detail for lower level tasks (e.g., 40/80 hour tasks)

- Considering the organizational structure of the project teams

- Determining the method(s) for capturing status (e.g., record task actuals or report task completion)

- Consider how the solution will be made available to the users

- Understanding the process for how stakeholders will have access to the plan data, either through the plan tool or by providing reports

Critical to the approach and strategy is ensuring that both the client and senior leadership commit to the discipline and rigor required to manage against the plan. How you provide status against the plan should reflect the way you will manage the work. Consider implementing a weekly cycle that requires participation from all of the work-stream project managers. The strategy should also consider how the program wants to report status out to its leadership and stakeholders and structure the plan and processes accordingly. The approach and strategy need to focus on the audience that it will serve, to include both internal and external stakeholders, as well as any contractual reporting requirements such as earned value management. Finally, think of the plan as one focal point looked at through multiple lenses for different reasons. The project team will look at it as their direction for delivering business capability to their client, the business sponsors will look at the value being delivered to them in a given timeframe, and executive leadership will use it to measure the health of the program.

Building the Plan

Estimating the Work

Prior to plan construction, the project teams need to develop detailed estimates defining the work to be performed based on the business requirements in the statement of work (SOW). Sound estimating processes are critical because they will provide the structure and scope to establish a program baseline plan. A standard approach across all work-streams is required for estimating consistency and needs to include estimating models and templates that map directly to the programs development life cycle. Development life cycles can and should be very detailed, defining all of the steps required to bring a business requirement from requirements definition through deployment of the requirement. It should not only consider the steps for the application development of the requirement but also any business process documentation, such as process model updates and training material development. The model should be developed with a work breakdown structure (WBS) that summarizes the development life cycle detail into manageable tasks (Exhibit 1).

Example Estimating Model with WBS

Exhibit 1 – Example Estimating Model with WBS.

The model generates estimates based on a set of drivers for each task type (e.g., document functional specifications). The drivers have a range of values representing the complexities for a given task type. The values for the drivers can be derived and customized from actual data collected on your current program or from prior experiences in the organization. Using standard values for these drivers provides for a consistent estimating process across all work-streams on the program. In addition to standard drivers, the model should also include a set of standard or generic roles. The roles should be developed so that they are detailed enough to generate program staffing requirements but not too detailed so that it becomes too difficult to level them when in the project plan. See sample generic roles in Exhibit 2 below.

Sample Generic Role Names

Exhibit 2 – Sample Generic Role Names.

As the teams develop their estimates at the task level, the model becomes a source for documenting assumptions about the scope of work to be performed. These documented assumptions bind the scope and become the basis for change control in the future should they change. Each of the task estimates in the model is driven by both the drivers selected and their complexity and they identify the generic role or roles that will be doing the work for that task estimate. These data are what eventually feeds the project plan for scheduling the work across the resource pool. When developing the estimates, consider roles that support the program in terms of process and guidance. Examples of these roles could be program management and architecture. These roles should be considered as level of effort resources across the program and not specific to the task estimates, for example, developing code for a business solution or creating training materials.

It is important for the teams developing the estimates to follow the program's processes and templates because they are the inputs that feed into the structure of the program's detailed project plan. Some models allow for automation into a planning tool and others require manual input. Either method works as long as the integrity of the data in both is consistent.

Develop Plan Structure, Level Resources, and Baseline

The basis of the project plan begins with the output from the estimating model. This can be supported by automated processes or manual techniques but, either way, when all of the tasks estimates and associated resource allocations are in the plan, you are ready for adding the building blocks to create an achievable schedule. The details and structure from the estimating model should align with the WBS that either is dictated in the SOW and/or aligns to how the program will report status to its stakeholders. After the estimating model has been inputted into the plan structure, the plans dependency chain should be created based on how the life cycle for each business requirement is executed as well as the internal and external dependencies across each work-stream's work efforts. Once the dependency chain has been completed, the plan is ready for resource leveling. The tasks from the estimating models initially include generic role assignments. These generic role assignments, by themselves, are not sufficient to build an executable project plan. Resource names must replace the generic roles prior to determining if the program is properly staffed and you can execute against the plan. A final step to determine a plan's viability is to “level the resources.” This step will confirm (or not) whether your plan is staffed properly, can execute against the schedule, and if the activities can be completed within budget. Leveling the resources can be accomplished by using manual techniques or through automation provided by the planning tool. Steps to accomplish this include:

- Manually schedule tasks where a predetermined schedule has been set (e.g., Workshop Deliveries, Solution Development Labs, Final Regression Testing).

- Prioritize components of work that have no predetermined schedule but have importance to the business with regard to their completion.

- Create resource profiles in the planning tool for each of the roles required to complete the work.

- Determine the tasks that have a set schedule and “lock” them down so that their defined schedules are not affected by the resource leveling algorithm of the planning tool.

Using a planning tool's leveling functionality takes practice and multiple iterations to adjust the resource profile to optimize both the resource load and schedule completion. As you work through the iterations of leveling the resources, reviews with both the project teams and leadership will be necessary to ensure the schedule meets expectations with the given timeframe and budget. After the plan schedule is stable and the resource loading is level, the resource profile should be analyzed to ensure it fits within the budget of the program. This analysis can be done using the planning tool or an external tool using the project plan data. A final review to gain approval from the work-streams of the schedule and resource loading with the work-stream managers prior to review with external stakeholders are important. The team should review the plan in detail to validate the following goals have been achieved:

- The plan has established clear goals, scope, deliverables and constraints.

- The team has a good comfort level with the plan estimates and timeframes.

- The plan has some built-in risk mitigation strategies and is linked to your risk management plan, where appropriate.

- The plan maps to the business objectives.

- The plan accurately models the way work will get accomplished.

- The plan provides a framework for proper reporting for each stakeholder group (e.g., hours expended, earned value, scope analysis).

- Each task has a purpose. If you can't answer “what is the work product for this task,” rethink the value of the task.

- Determine upfront the metrics required from the plan; you only plan once, but you will manage against the plan for the program life.

- You can gain concurrence with senior leadership and client stakeholders.

Communicate the Plan

Throughout the process of developing the plan, interim reviews and feedback with both your leadership and client are necessary so that the program presents the final results in unison to the business stakeholders. The team should summarize the details of the plan so that deliverables and schedules are presented at the correct level based on the audience the plan is being communicated to.

Communication varies at many different levels of the program and also varies depending on where you are in the program's life cycle. The messages will also differ. Exhibit 3 below depicts how understanding the program level affects time frames and communication of decisions.

Program Level Affects Time Frames and Communication of Decisions

Exhibit 3 – Program Level Affects Time Frames and Communication of Decisions.

(Copyright © COMPUTER SCIENCES CORPORATION, 2012)

When communicating the schedule to different audiences, consider the level of detail the message requires for each.

- Executive Leadership and Senior Management – High level schedules with critical milestones and long-range plans.

- Program Management – Critical activities schedules, functionality release schedules, resource requirements.

- Project Teams - All of the above, plus detailed activity and task schedules and resource assignments.

Execute, Monitor, and Control the Plan

The plan is established and the baseline is set, now the hard part begins! Many large programs fail to execute disciplined plan maintenance processes that are critical for measuring performance against the baseline that was agreed to with the stakeholders. These processes include a weekly status update that requires inputs from all resources contributing to the progress of plan activities as well as a disciplined baseline change control process. Both of these processes take a serious commitment from the project teams, the program management office, and the client's project management organization. A key area supporting these processes is resource acquisition and management. Resource management strategies will depend on how your program can operate within the structure of the contract. But in terms of executing against the baseline plan, some fundamental processes must be considered:

- Assigning specific resources (i.e., project team members) to planning roles for a 4- to 6-week horizon.

- Pooled resources versus team-based resources. Leverage resources across the program when possible.

- Monitor resource utilization for each named resource, by role type, and in aggregate.

- Manage capacity and demand on an ongoing basis.

- Allow adequate lead time to acquire resources. Considerations include source of supply and market conditions.

Additionally, defining clear ownership of each task and resource in the project plan is just as important and is the project manager's responsibility. Each task on the plan within the program's assignment window (e.g., 4 to 6 weeks) must have the named project team member(s) responsible for completing the task assigned to the task. Also, team members should be aligned to a team manager and organization, so that the intersection of the tasks in the plan and the team members can be analyzed and managed from both a schedule and resource load perspective. Weekly assignment tracking and communication of progress by team members to their manager and by the manager to the program management office maintaining the plan are essential for status.

Status of each task can be achieved by utilizing tools specific to the planning application that the program is using. Commonly used are Task Turnaround Sheets (TTS). Every resource assigned to a task on the plan records his or her status in terms of work performed and remaining work. The TTS are the foundation to weekly plan updates, but are only the beginning. Manager review of their team members' TTS prior to input into the project plan is an essential step in the maintenance process to ensure that the data being entered into the plan are accurate. The manager should have the capability to adjust an individual TTS when he or she finds errors or inconsistencies. Automation of the task turnaround sheets into the planning tool helps compress the time to process each sheet, reduces management effort, and improves plan accuracy. Additionally, every work-stream manager must participate in weekly reviews of his or her plan or plan component. These manager reviews provide another layer of fidelity to the schedule, work effort estimates, and resource loading. This is important so that when status is reported out to the program stakeholders, the work-stream managers responsible for their area take ownership in the data representing their status.

Most importantly, when executing against the baseline project plan the program must establish a disciplined management cycle and adhere to it. A weekly cycle is recommended so that risks to the schedule can be identified quickly as opposed to a monthly process when identification of a schedule slip could be too late. A disciplined weekly process helps to determine the current status of the project schedule. It identifies influencing factors that create schedule changes and supports validation of actual schedule changes as they occur. An example of the weekly cycle is depicted in Exhibit 4 below.

Weekly Plan Maintenance and Management Cycle

Exhibit 4 – Weekly Plan Maintenance and Management Cycle.

(Copyright © COMPUTER SCIENCES CORPORATION, 2012)

Part of the weekly plan maintenance process includes a strict baseline control process. This should be a formal documented process for any change to the scope of work that was estimated and agreed to in building the program's project plan. It should be one of the program's official documented processes that has input by both the program management office and the client. The process should include a governance board for reviewing all program baseline change requests and to determine their disposition.

The scope baseline (established by the customer requirements) is linked to the development life cycle, and estimated via the program's estimating process. During that process, the assumptions about the work to be performed and its make-up and complexities were documented. If during the execution phase these assumptions do not hold true, a change would need to be evaluated. All changes to the project baseline must be analyzed in terms of cost, schedule, and scope and formally documented, presented and reviewed for disposition in accordance with the program's baseline change processes. Strict discipline to baseline control must be implemented to ensure accurate status reporting.

Monitoring the status of a large program is all about providing data that show where the program is against its baseline at the time of the reporting period and projecting its future based on estimates from the team members and managers. Establishing and following disciplined plan maintenance and baseline control processes are critical to support business decisions on the program. Large program plans produce large volumes of data to analyze. In order to help focus program leadership, executive management, and client management on the areas requiring attention, consider creating a “program dashboard.” The dashboard should report key metrics, tailored to the current program life cycle (e.g., summarized life cycle metrics, work effort variances, critical path analysis, late starts, and late finishes). Your program dashboard can also integrate other program processes, such as risk and issues management where the data are not obtained from the project plan. An example dashboard is displayed below in Exhibit 5.

Example Program Dashboard

Exhibit 5 – Example Program Dashboard.

(Copyright © COMPUTER SCIENCES CORPORATION, 2012)

Conclusion

Although a number of factors influence the success and/or failures of large programs, sound project planning basics hold the keys to ensuring a successful outcome. Principles and methodologies that support discipline and rigor are necessary to achieve the program delivery on time, on budget, and at the highest level of excellence. Your program schedule is the roadmap for the direction of the program and you need to ensure you know where you are at all times along its route. Use disciplined estimating, plan construction, change control, and plan maintenance processes for accurate measurement of your status and stay on track by using a weekly control cycle. Remember, the project managers are critical for ensuring that the plan is accurately maintained and that it holds the truth in terms of program status. Their commitment to the application of these planning techniques improves management visibility and decision making, increases client satisfaction, and helps to ensure the success of the program.

Plan the work, work the plan. And, remember, discipline is THE critical success factor!

References

Presentations

Brisgone, A. (2007). Project management development program – Cohort “F” project time management. Marlton, NJ: CSC Project Management Development Program,

Brisgone, A. (2010). Integrated Master Schedule (IMS) & Integrated Master Plan (IMP). Marlton, NJ: CSC North American Public Sector FCP Alpine Training.

Hearrington, S., Brisgone, A., & Bryson R. (2006). Project planning, execution, and control on the Army Logistics Modernization Program (LMP). Marlton, NJ: CSC Project & Program Management Community.

Hearrington, S., Galasso R., Hilgendorf K., & Sarna D. (2011). Secret sauce of successful projects. Marlton, NJ: CSC Project & Program Management Community.

Advertisement

Advertisement

Related Content

  • Project Management Journal

    Explorative Learning in Infrastructure Development Megaprojects member content locked

    By Liu, Yan | Hertogh, Marcel | Yuan, Ziwei | Liu, Huimin This research draws upon the case study of the Hong Kong-Zhuhai-Macao Bridge (HZMB)--a cross-sea link construction project--to study how explorative learning was achieved and sustained.

  • Project Management Journal

    Using Principal–Steward Contracting and Scenario Planning to Manage Megaprojects member content locked

    By Turner, J. Rodney Megaprojects are complex, but people use constructs inappropriate in complex situations for their management, particularly contractual arrangements.

  • Project Management Journal

    Coping With Institutional Complexity and Voids member content locked

    By Fu, Yongcheng | Zhang, Lihan | Chen, Yongqiang This study investigates how transnational interorganizational projects (IOPs) cope with institutional complexity and voids.

  • PMI Case Study

    Saudi Aramco member content open

    This in-depth case study outlines a project to increase productivity with Saudi Arabian public petroleum and natural gas company, Saudi Aramco.

  • Project Management Journal

    A Dynamic Capabilities Model of Innovation in Large Interfirm Projects member content locked

    By Steen, John | Ford, Jerad A. | Verreynne, Martie-Louise The time-bounded nature of large interfirm projects and technical interdependencies constrain innovation.

Advertisement