Developing a Robust Programme

Developing the programme of a project is about identifying and presenting activities, their sequence, dependencies, duration, start and completion dates, resource requirement along with the milestones, control points and project constraints. The project programme can then become the project’s baseline for tracking purposes. Iterative revisions and maintenance of the programme are tasks that the project manager must adhere to for the life of the project.

Following documents contribute to the development of a project programme.

  • Project Management Plan
  • Project Documents, Agreements
  • Enterprise Environmental Factors
  • Organizational Process Assets.

Inputs to the Programme

Inputs to developing a programme include the following:

  • Programme Management Plan – is the management plan that defines the guidelines for how scheduling efforts should commence, what approaches to take, the degree of accuracy, and many other possibilities.
  • Activities List – The activities list can be used to align specific details to the project programme. For relatively simple projects, the activity list may be something that a project manager maintains, as deliverables are completed, the project manager progresses to the next line item activity. For more sophisticated projects, the process itself is very similar but takes into consideration predecessors and successors and other pertinent information based upon the project’s activity attributes.
  • Activity Attributes – Activity attributes support the activities. While this is an iterative process, it is important that the project manager and team use the process for progressive elaboration to gain additional knowledge regarding project deliverables.
  • Network Diagrams - Project managers need to understand the process of developing a network diagram. This helps the project managers to understand the logic applied to network diagrams and, over time, he or she will be able to understand activity sequence details based upon visualization provided through network diagrams. The benefit of applying network diagrams is that the project team can review a workflow that details each deliverable within the project and illustrates the relationship of each work package to one another.
  • Resource Requirements - Resource requirements impact project duration based on the availability of resources required for durations within the project. By taking resource requirements into consideration, the project manager needs to ensure that the right resources are available at the right time to develop project deliverables.
  • Resource Calendars - Resource calendars help illustrate activities based upon a time continuum that can be easily managed. The benefits of resource, calendars are that the project team can easily view planned events on the horizon to ensure both human resources and materials are available on the anticipated date and in the anticipated location.
  • Duration Estimates - Naturally as the project team develops the programme, the duration estimates are applied. The benefits of incorporating duration estimates can be seen by accumulating all estimates to arrive at a total duration of the project. This total duration can be compared to planned activities and measured on an ongoing basis.
  • Project Scope Statement - The Project Scope Statement will provide details relating to assumptions and project constraints. The benefits of incorporating scope statement details again apply to the iterative nature of project templates and the ability to maintain checks and balances throughout the life cycle of the project. Risk Register and Project Staff Assignments.
  • Risk Register - The list of potential risks that could impact the project and more specifically in this context the programme – either positively or negatively. These identified risks must be considered and revisited often when developing a programme, hence the calling out of the Risk Register as an input.
  • Staff Assignments - Who you have available or do not have available can play a major role in the programme development. Have the wrong skill set of a resource or having the right resource but at the wrong time are just a few of the possibilities.

Project Programme Tools

The most common technique regarding programme network analysis is the critical path method. The critical path method calculates the early start and finish dates, as well as the late start and finish dates for all activities, from initiation to completion. Using early start, early finish, late start, and late finish dates enables the project manager to perform both the forward and backward pass regarding the duration of work packages within the nodes incorporated in the network diagram. Early start, early finish, late start, and late finish simply indicate time periods for the activities scheduled.

The critical path method considers the possibility of a resource float, which provides for a degree of flexibility in scheduling project activities. The term “total float” on any network path reflects on the programme flexibility by measuring the positive difference between early and late completion dates for work packages. The term “free float” represents the amount of time an activity can be delayed without delaying the early start date of any of its successors.

Monte Carlo Analysis - A common technique aligned to what-if scenario analysis is known as the Monte Carlo analysis, as in the casino, since it is based on “hedging your bets” on odds and probability. The distribution of possible outcomes is defined for all activities and used to calculate a distribution of the entire project. Within the Monte Carlo technique, repeated random samplings and probability distributions are computed as simulations of activities. Those simulations deliver results that are then compared and analysed to determine the alternative with the highest probability of occurrence.

Leads and Lags - Leads and Lags can act as refinements applied during network analysis to help smooth the project programme.

Smoothing is a technique used to address conflicts within a project. Smoothing is considered a No-Solution technique because nothing is resolved by smoothing. With Smoothing, the project manager concentrates on areas of agreement to progress activities. When it comes to addressing conflicts within a project, smoothing is one technique available to the project manager.

Here are a few more techniques: Confronting, this is where opposing sides address concerns directly for a Win-Win solution; Compromising happens when opposing sides partially relinquish positions for a Lose-Lose solution; forcing is when there is a Win-Lose solution; and Withdrawal is similar to Smoothing where no solution is produced.

Programme Compression permits the project manager to compress the project programme without impacting scope. The most common technique for programme compression is known as crashing, where costs and programme trade-offs are reviewed to determine the greatest degree of compression at the lowest possible cost. Crashing only works for work packages where additional resources can shorten the task’s duration.

Outputs of 'Develop Programme Process'

The outputs of the Develop Programme Process are the actual project programme, project baseline, and supporting documents. These documents will be used, reviewed, and updated throughout the life of the project. The project programme is typically presented as a table and accompanied by the following:

  • Milestone charts - Milestone charts are not part of the overall project plan; however, they detail time-bound perspectives relevant to the overall productivity of the project. Milestones enable the project team to measure progress. A milestone chart is simply a graphical illustration of milestone activities.
  • Bar charts – Bar charts illustrate project activities relevant to start and end dates along with overall durations. Most bar charts come in the form of what is known as a Gantt chart, which is frequently used to illustrate project programme activities. The Gantt chart illustrates activity start and end dates along with predecessor and successor dependencies. It is the preferred method to illustrate the progress of project activities and is a major component of software applications such as Microsoft Project.

Keeping the Project on Track

Controlling a project programme ensures that the iterative processes executed continue to drive activities that meet stakeholder expectations. It also monitors the status of project activities to update project progress and manage changes to achieve plans. Within this process, the project management plan, project programme, and performance information contribute to analysis and reviews that help the project team determine preventive or corrective actions that will help keep the project on track. As a product of this process, work performance metrics, and organizational process assets are updated.

Formal change requests, known as Requests for Change, or R-F-C’s, are also instituted based upon findings and adjustments to requirements that took place throughout the prior processes. Once changes are identified, a formal request is submitted for review to a formal change control board; they can then be scheduled for incorporation into the project management plan, all subsidiary process documents, and the project programme. At this point, the project document updates provide details in regard to relevant changes that are saved as an artifact of the project for future project considerations.

Tools for Controlling Programme

Tools for controlling the programme are applied to control inputs to determine corrective or preventive actions that may need to be applied in order to maintain the project programme. These tools promote transparency and mitigate risk that may develop as the project progresses. Tools to control programme include:

  • Performance reviews provide metrics in regard to the overall progress of the project. They incorporate metrics such as earned value management and programme performance indices to assess programme variations and determine mitigation activities if required. Performance reviews help indicate when and where corrective action needs to be escalated and addressed. Performance reviews can be an informal or formal process that provides updates pertaining to all project activities
  • Variance Analysis -The Variance Analysis process compares actual activity from the project programme with the programme baseline to deliver metrics that pertain to project work performed. This work is analysed against costs associated with delivering the work in the programme intended to deliver the work by. Project control and governance are based upon those metric ratios to determine requirements for corrective, preventive action or defect repairs.
  • What-If Scenarios provide a review of multiple scenarios that may be required to realign programme activities with the project plan. A prudent project manager will always ask the question "What If…" in regard to risks in project activities that promote or require a change

Outputs of Controlling the Programme

Outputs of controlling programme contain productivity metrics and processes to incorporate changes required by the project. The outputs keep the project management plan current and assist the project team in managing the project programme within the constraints of the project’s critical path. The outputs include:

  • Work performance information - Performance metrics easily calculate formulas that you will be required to execute for project management certification. These formulas are known as earned value metrics and they allow the project manager to determine values such as Earned Value, Actual Cost, Planned Value, Cost Variances, and Performance Indices. Each of these values has a specific formula attributed to it, and they incorporate simple arithmetic to arrive a value.
  • Organizational process assets updates - Process assets that should be updated as artifacts include descriptions of project variances identified, corrective action plans, and project lessons learned. All of these activities become artifacts and are relevant documents that provide historical information pertaining to project activities.
  • Change requests - All modifications to the project plan require a change to the programme. All changes to the programme require change requests to ensure that a process applicable to the change is documented, detailed, executed, and managed. Change requests are reviewed to the Perform Integrated Change Control process. Changes can be either approved or rejected, with rejected changes either being turned down completely or sent back for modification.

要查看或添加评论,请登录

Muhammad Bhatti的更多文章

社区洞察

其他会员也浏览了