Lesson 19: Project Close Out

Rather than writing a BLOG on Close Out, here are a few good websites dealing with the subject:

• Wiki Books
• Lorman Education 
• Max's Website 
• American Institute of Architects

Lesson 18: The Schedule Bar Chart and Responsibility Matrix

The Schedule Bar Chart provides a perspective of the activities/tasks of the project on a time line, and could indicate the relationships and critical path as well as slack per activity.

The Responsibility Matrix provides a clear delineation of roles and responsibilities, based on the WBS. This is done at activity level and provides an overview of who will be responsible and support task/activity execution.

Click here below to obtain an overview of how the Schedule Bar Chart is Created and related to that, how roles and responsibilities are assigned with the aid of the Responsibility Matrix:

Focus on CPM and Resp Matrix

View more presentations from dmdk12.

Lesson 17c: The Network Logic Diagram Practical

Click here for a practical example of how to create the Network Logic Diagram and calculate the Critical Path:

The Network Diagram and Critical Path

View more presentations from dmdk12.

Lesson 17b: The General Rules for the Network Logic Diagram

By now the general principle for creating a Network Diagram should be clear. There are however additional rules for creating this sequence of activities. These are outlined below:

• Networks typically flow from left to right
• An activity cannot begin until all of its preceding activities are complete (the most basic relationship is the so called "Finish to Start" relationship)
• Arrows indicate precedence and flow
• Looping is not allowed- a Network Diagram is not a process flow
• Conditional statements are not allowed
• Use distinct start and finish tasks - start with one task, finish with one task (the general rule is, if you do not have a logical start and finish task, then create one)

The next blog will take the case example and create a coherent Network Diagra upon which the Critical Path calculation lessons will be based.

Lesson 17a: The Network Diagram

In this series of lessons the Network Logic Diagram will be discussed, and animation slides provided to show how this important project management tool is created. First however, here is an overview of the Network Logic Diagram:

• Just a quick reminder that the WBS, is a decomposition of the final deliverable, to sub-deliverables to activities/tasks. This constitutes the scope of work to be done and deviations from this should mandated properly to prevent scope creep
• Whereas the WBS tells us what work needs to be done to generate deliverables, the Network Diagram tells is what activities should be finished before other activities can start
• Remember that two things can basically determine what should be finished before something else can start i.e. the nature of the tasks we are busy with (in which case we refer to it as a logical or technical constraint) and other other factors, where our in our own discretion we decide that something must finish before something else should start (for example we want to ensure resources are utilized optimally)
• Also remember that the Network Diagram is a relationship diagram. We create relationships between tasks, and thereby indicate which tasks are the predecessors of one or more tasks. We also refer to these relationships as dependencies, because by creating the relationships we construct a coherent network where each task is somehow dependent on tasks preceding and following in the total network

CLICK AND PLAY FLASH ANIMATION FOR VISUAL EXPLANATION:

Read more: http://www.whitehatandroid.com/2009/10/flash-blogger-embedd-upload-swf.html#ixzz0kmoPYpJv
Under Creative Commons License: Attribution Non-Commercial Share Alike

Lesson 10: Organizational Context

This BLOG provides answers to three important questions related to projects and project management. The first is where do projects typically originate? The second, who are the key role players and the third how does the organizational culture influence project outcomes? The paragraphs that follow provide more detail in this regard:

Where do projects originate?

The question, where projects originate is important in that it provides insight into what should be regarded project work and what not. This is best illustrated through and example. Consider the management team of a company that manufactures mid-sized vehicles for the urban commuter. Further assume that this company do their annual strategic planning and realize that they will have to contribute to reducing carbon emissions. Based on this they decide to investigate ways to adjust their production processes to accommodate the new strategy. Thus, a new initiative is born, while at the same time the normal production work continues. However this broad strategy is not a project yet . An optimal solution needs to be found, feasibility tested etc, prior to this. The important point however is that in most cases projects originate from new strategies initiated by top management . Further, that prior to launching a specific project the new initiative needs to be prioritized, and potential solutions need to be investigated. It is here where research is done, and feasibility of the potential solutions modeled. Once an optimal solution is found the project moves into the cycle to produce the final deliverable

Key Role Players (Stakeholders)

In the previous lessons the importance of managing expectations were mentioned. It needs to be realized that, for stakeholders to have a clear sense of what the benefits will be from producing the final deliverable, they need to be kept "in the loop" .This also implies they need to be identified as soon as possible. While authors differ about the exact definition of what a stakeholder is, it is useful to identify those role players who have an interest ('stake') in the project and can influence its outcome. The main stakeholders in this regard include the following:

• Project Manager - the individual responsible for managing project work
• Customer/User/Beneficiary - the individuals, group or organization who will use the product or benefit from the solution
• Sponsor - the individual or group who represent those who provide finance and also "owns" the business case
• Performing Organization - the individuals, groups and organizations who would probably be involved in the planning and execution of the project as well as ongoing maintenance following delivery

Organization Culture

It should always be remembered that projects are not planned and implemented in a vacuum. The culture of the organization is a strong force that needs to be navigated to ensure that the final deliverable is produced. Per definition the organization culture is a set of assumptions (learn t over time) upon which organization behavior is based. While culture is difficult to identify it is also true that it affects everything that happens in an organization. In terms of this think about the "artifacts" like the building, what the boardroom looks like, etc. What does is say about "the way we do things here"? It is this way things are done, that needs to be taken into account and the only way to negotiate through this and deliver is to ensure that you keep control of the Iron triangle and manage expectations effectively.

Lesson 9: The Project Cycle In More Detail

While Lesson's 1 to 6 provided an overview of the basic definitions and core concepts related to project management this BLOG provides insight into the core techniques that need to be mastered in each phase of the project cycle. This BLOG also answers the question - from a management perspective, what do we do in each phase of the project cycle? he paragraphs that follow highlight this in more detail:

Initiation Phase:

In the initiation phase the main task is to define the project. The aim is to ensure that we have the basis for what needs to be done in the other phases of the project cycle. The tangible output of this phase is the so called project charter. It is the charter that, once approved, provides a mandate to officially start - thus, following approval of the charter we have a project...

The outputs of this phase include the charter, clarity about the problem, the final and high level deliverable s as well as other aspects that forms part of the basic definition of the project - important in this regard to identify the key stakeholders as early as possible

Planning Phase:

The bulk of the work of scoping out the project, sequencing, scheduling and budgeting takes place in this phase of the project. There are also very specific techniques that need to be mastered here, notably how to create a work breakdown structure (WBS), a network logical diagram, calculate a critical path (CPM) , as well as developing the schedule bar chart and budget.

The main outputs of this phase are clarity about the technical/functional specification (albeit not strictly a project management output), the scope of work (in the form of the work breakdown structure, the network logic diagram, the schedule bar chart and the budget.

Implementation Phase:

In the implementation phase the project manager essentially drives execution, manage changes to the scope (change control), and make sure that the expectations of the stakeholders are aligned with the benefits the final deliverable will produce. Remember your success as project manager depends on your ability to manage expectations!

The main outputs of this phase include:

• Tracking status - this includes tracking the schedule, managing action items (actions too small for the schedule but often gets scheduled items done) and issues (problems that could escalate)
• Reporting status - this includes reporting on the above but also providing evaluations/interpretations to the client and recommending strategies and actions
• Driving execution - this includes keeping an active pulse on the status, making status visible, taking corrective action and keeping the customer "in the loop" (the last forms a huge part of expectations management)

Close Out Phase:

The close out phase is where the project team makes sure that an independent audit is conducted, the client system is capable to sustain the benefits derived by the final deliverable, debriefing, project accounting and redeployment of team members are done. The main outputs here would be the final payments, commissioning, and a close out report signed off by major stakeholders

Lesson 5: The Iron Triangle

In all projects the manager has three elements he/she needs to control. The elements are the scope of the project, the costs and the time within which delivery needs to take place. These are referred to as the “iron triangle” and the good project manager constantly try to use the leverage available in these elements to ensure that the project moves forward to completion. Examples of how this leverage is used includes the following:

• If time is limited, the project manager would try to use more resources, or negotiate a change in scope to finish in time
• Where finance is limited (cost) the project manager will have to take a view and decide whether the scope should not be changed

An over determined project is one where all these aspects are fixed (cost, scope, time). Such projects are impossible to manage and often destined to fail.

Iron Triangle

View more presentations from dmdk12.

Lesson 4: The Project Cycle

All project work is executed in the project cycle. It is the anatomy of a project, and consist of four phases:

• Initiation - this is where we obtain clarity about the problem, the final deliverable/solution/product and the benefits. Further also the scope of work
• Planning - here we decide how long the project will take (durations), and what resources are required (how much)
• Implementation - here we build the final deliverable
• Close Out - Essentially we close out from and administrative and accounting point of view and evaluate or efforts

Unfortunately, because not enough time is spent in the initial phases (initiation and planning) we design problems into the project. These problems are often only discovered in the implementation phase, and becomes very difficult to solve.

The lesson - make sure you address the right problem, define and plan the project well!


The following slide-show is a visual aid to help explain the idea ( you can download it from Slideshare)

The Project Cycle Revisited

View more presentations from dmdk12.

Lesson 3: Main Project Artifacts

The previous BLOG provided an overview of the nature and characteristics of a project. This BLOG moves further and outlines the main "artifacts" of the project, from a delivery perspective. If one asks the question - what should a project leave behind after successful implementation, three things come to mind:

• A deliverable/product or solution
• Benefits
• Tasks

The deliverable/product/solution aims to solve a problem. In respect of this the key is to know what the problem is, whether it is real and to make sure that the deliverable, etc will solve the problem.

The benefits are derived from solving the problem, and as such it provides the basis for the business case

The tasks in a project are performed to produce the deliverable/product/solution.

Because the benefits of a project are often oversold ,the expectations of the client are not aligned with the real benefits that will be derived from production of the final deliverable. The result is that, while projects often deliver, the project is still perceived to be unsuccessful. In this regard it is important to realize that the project team can only provide the deliverable/solution/product and that the project is essentially over when this was achieved. The success and credibility of the project manager though is dependent on the extent to which expectations can be managed.

The slide-show below encapsulates the essence of the discussion and can be downloaded.

Projects- The Three Artifacts

View more presentations from dmdk12.