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 16: Completed WBS

This BLOG includes an example of the WBS as per the case study outlined in Lesson 12. The WBS was created in MS Visio, then also in Mind Manager. Links are provided to download the original files for use on a creative commons basis. if you click on the picture included in this BLOG it will enlarge and enable you to see the detail of the WBS.

Here are the links to the relevant files (note you have to register - free) to download the files:

• Click here for Mind Manager version of the WBS

If you do not have the software to open the files here are links to download free viewers:

• Mind Manager Viewer

Lesson 15: WBS Quiz

Lesson 15 Quiz: Building the WBS » Test maker

Lesson 14: The Work Breakdown Stucture (WBS)

Building on the previous lessons and taking the case study as departure point it is possible to move further and do detailed scoping for the project. Although the exercises in the previous lessons did not require full development of the Project Charter, let us assume that we have been able to define the final deliverable and high level deliverable's of our aircraft assembly project as follows:

Final deliverable:

Assembled Airbus, ready for its first airworthy inspection prior to first test flight (from here on we will just refer to this deliverable as - "Assembled Airbus")

High Level Deliverable's:

To keep it very high level and not complicate our case study, our high level deliverable s will be very general. However, remember that the high level deliverable should be such that it produces the final deliverable:

• Assembly plant secured
• Workforce appointments completed
• Component delivery check-in completed
• Sub-component assembly completed
• Interior fitted
• Final assembly completed
• Handover of aircraft completed
  

With the above clarified (albeit at a very high and general level) the next phase of the project can be embarked upon. In this next phase (the Planning Phase of the project) one of the first tasks would be to define the scope of work. This is achieved by developing a Work Breakdown Structure (WBS).

Per definition the WBS has two main elements:

• A hierarchical outline (map) that identifies the products (deliverable's) and work elements involved in the project
• This map defines the relationship of the final deliverable to its sub deliverables' and in turn, their relationships to work packages (collection of elements related to work that must be done)
  

Lesson 13: Quiz For Charter Case Study

Quiz For Charter Case Study » Free Online Quizzes

Lesson 12: Charter Case Study

In order to exercise our skills in defining the project let's use a practical case study (admittedly a bit superficial, but done for the purposes of teaching). Embedded in this BLOG is a time lapsed video that provides an overview of how an Airbus A380 gets assembled. Let us further assume that we are the team responsible for the assembly, but only the assembly. To make sure it is a project, also regard this as the first prototype that will be tested. Doing this at a very, very high level (after all few of us are aeronautical engineers) the client put the following conditions to our involvement:

• We are only responsible for assembly  and  branding (major components - fuselage; wings; landing gear; navigation equipment, interior and painting)
• We are assemblers not engineers, definitely not design engineers
• The assembly plant will be provided, but not the support staff, who you need to appoint and manage them
  
• Final quality check prior to first test flight will be done by external contractor

Now watch the video and move on to the next lesson and answer the multiple choice questions.

Lesson 11: The Project Charter

This BLOG essentially starts the skills building part of this whole series. From this point onwards focus will be on developing skills to master the techniques required to complete each phase of the project cycle. As such this first BLOG in the series deals with the initiation phase and provides a detailed overview of what elements the Project Charter will address. Reflect back on Lesson 9, where the project phases were discussed. In this regard it was highlighted that the Initiation Phase is where the project is defined, the main tangible output being the Project Charter. Let's look at how the detail of the project Charter enables clarification and definition of the core elements of the project:

STRUCTURE OF THE PROJECT CHARTER (DOWNLOAD TEMPLATE HERE)

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 8: Flashcard Review

Lesson 1-6: Flashcard Review » flash card maker

Lesson 7: Review

Review Lesson 1 to 6 » Quiz Question Maker

Lesson 6: Deliverables and Tasks

Expanding on the ideas put forward in Lesson 3 (Project Artifacts), it is necessary to clarify the notion of deliverable/product/solution and task/activity (remember in project management task and activity are used interchangeably as is the case with deliverable, product and solution ).Per definition a deliverable is referred to as something that has been produced. Thus, for planning purposes a deliverable is often stated in the past tense and is the practical (tangible) manifestation of what would be produced.

An important characteristic of a deliverable is that it does not consume time, and resources for the purposes of project planning, budgeting etc

Tasks in the other hand refer to the work that will be done to produce a deliverable. For planning purposes tasks usually have a verb in the sentence and consume time and resources. Here are some examples of deliverable and tasks:

• Deliverable: Building plans approved
• Task: Digging the foundations (of a house)
• Task: Laying bricks
• Deliverable: Pavement completed for inspection

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.

Lesson 2: The Definition of a Project

Any sort of understanding about projects, and project management starts with the definition of what a project is. Here is the definition according to the PMBOK.
“…a project is a temporary endeavor undertaken to create a unique product or service… “

Let us consider the core elements here:

• Temporary means that every project has a defined begin or end state
• Projects are also unique in the sense that the aim is to produce something that is distinguishable from all similar products and or services

That leaves us with an unexplained acronym - The PMBOK:

"The body of knowledge developed by the Project Management Institute, representing the work done by most project managers most of the time"

Lesson 1: Introduction

Why is project management the preferred way to organize in the modern economy? The short answer is that social-economic complexity fueled by technology development created:

A networked world
A global economy, that is operating independently of time and space

In this world, competition and the need to develop new products, services are immense This networked world created a need to change while at the same time keeping the normal business running, and it is because of this that project management in all functional areas seem to be the preferred way to organize. The video clip below provides some insight into the dynamics at work in the modern economy.