next generation project management systems -a quality approach

8/8/2019 Next generation project management Systems -A Quality Approach .

1/124

Next Generation Project management systems A Quality

Approach

1

IntroductionImplementing Quality Management Systems using Project management techniques to projects: A

systems approach to Planning, Scheduling and Controlling Innovative approach..

Executives have realized that Project management and productivity are related to each other, both

trying to make effective and efficient utilization of existing resources. This project work is

developed to provide hands on approach to learning the necessary tools and techniques by which

activities can be integrated throughout the organizational size, project complexity, or type of

industry.

The purpose of this research is to contribute to a better understanding of project management

practice by investigating the use of project management tools and techniques and the levels of

support provided by organizations for their use. The study examines both general levels of use

and variations among project types and contexts. Many aspects of project management practice

are common to most projects in most contexts, while others vary significantly among different

types of projects and among projects in different contexts. The purpose of this paper is to present

empirical results that show both the common elements and the significant variations. The paper is

based on a survey of many experienced project management practitioners. The use of tools and

techniques is seen here as an indicator of the realities of practice. The study found some aspects

of practice to be common across all types of projects and all contexts, but on this background of

similar patterns of practice, several statistically significant differences have also been identified.

The primary focus of this paper work is on these variations in practice.

Aims and objectives:

Building a Next-Generation Program Management and Portfolio

Management

Instead of defining roles and making sure team members are following project

management processes and procedures to , next generation project managers need to

focus on improving collaboration and removing obstacles and distractions so that project

members can get their work done on time and on budget.


2/124


Approach

2

While the Project/Program Management Office (PMO) continues to be a growing

trend in recent years, the reality of the turbulent business environment is posing new

challenges for implementing and sustaining PMOs. The pressure to deliver value and

reduce overhead has created a need to find innovative approaches to enhance the

PMO to the next level. Whether you are building a PMO to support and enhance

project management capabilities, or as a governance structure, or to focus on strategic

aspects of Portfolio Management, you may encounter implementation challenges and

mixed results. While the PMO can offer tremendous benefits and have strategic

impact, the challenge is in the focus of the PMO and the way it is implemented. How

can you find innovative ways to build and sustain a PMO that can address the

challenges and critical success factors to overcome the barriers? What is the role of

the PMO in delivering business strategies? How does it fit with Program and

Portfolio Management? What organizational structures, functions, processes and

practices will ensure success? How can you sell and demonstrate PMO value and

Return on Investment (ROI)?

Need for studyThe purpose of this research is to contribute to a better understanding of project management

practice by investigating the use of project management tools and techniques and the levels of

support provided by organizations for their use. The study examines both general levels of use

and variations among project types and contexts. Many aspects of project management practice

are common to most projects in most contexts, while others vary significantly among different

types of projects and among projects in different contexts. The purpose of this paper is to present

empirical results that show both the common elements and the significant variations. The paper is

based on a survey of many project management practitioners. The use of tools and techniques is

seen here as an indicator of the realities of practice. The study found some aspects of practice to

be common across all types of projects and all contexts, but on this background of similar

patterns of practice, several statistically significant differences have also been identified. The

primary focus of this paper is on these variations in practice.

The Project Management approach requires departure from the traditional business organizational

form which is basically vertical and which emphasizes a strong superior-subordinate relationship.


3/124


Approach

3

Understanding Project Management:

In order to understand Project Management, one must begin with definition of project .A project

can be considered to be any series of activities and task that:

Have specific objective to be completed within certain Specification.Have defined start and end dates.Have funding limits.( if applicable )Consume resources ( i.e. Money, People ,Equipment )

Project management involves Project Planning and Project monitoring and includes such items

as.

Project PlanningDefinitions of work requirements.Definition of quantity of work.Definition of resources needed.Project Monitoring

Tracking progress.Comparing actual to predicted.Analyzing ImpactsMaking adjustments.Successful management can then be defined as having achieved the project objectives:

Within timeWithin CostAt the desired performance /Technology level.While utilizing the assigned resources effectively and efficiently.

The potential benefits from Project Management are:

Identification of function responsibilities to ensure that all activities are accounted for

regardless of personnel turnover

Minimizing the need for continuous reporting Identification of time limits for scheduling Identification of a Methodology for tradeoff analysis.


4/124


Approach

4

Measurement of accomplishment against plans.Early identification of problems so that corrective action may follow Improved estimating capability for future planning

Knowing when objectives cannot be met or will be exceeded.

Unfortunately, the benefits cannot be achieved without overcoming obstacles such as:

Project ComplexityCustomers Special RequirementsOrganizational Restructuring Project risksChanges in Technology Forward Planning and Pricing

Project management can mean different things to different people .Quite often, people

misunderstand the concept because they have ongoing projects within their company and feel that

they are using Project management to control these activities .In such a case, the following might

be considered as appropriate definition.

Project management is the art of creating the illusion that any outcome is the result of aseries of predetermined, deliberate acts when, infact, it was dumb luck.

Project management is designed to make better use of existing resources by getting workto flow horizontally as well as vertically within the company .This approach does not

really destroy the vertical , bureaucratic flow of work will be accomplished more

smoothly throughout the organization. The vertical flow is still the responsibility of Line

Managers.

The Figure Shows how many companies are structured .There are always Class or prestige

gaps between various levels of management .There are also functional gaps between working

units of the organization .If we superimpose the management gaps on top of the functional gaps

,we find that the companies are made up of small operational islands that refuse to communicate

with one another for the fear that giving up information may strengthen their opponents .The

project managers responsibility is to get these islands to communicate cross-functional toward

common goals and objectives .


5/124


Approach

5

Project management is planning ,organizing ,directing and controlling of company

resources for a relatively short term objective that has been established to complete

specific goals and objectives .Furthermore ,Project Management utilizes functional

personnel ( the vertical hierarchy ) assigned to specific project ( the horizontal hierarchy )

.

Research methodology

Project Plans

Firstly, one needs to make sure we are all on the same page when it comes to what a plan is.

Many people (and a distressing number of project managers, too) think only of a Gantt chart

when they think of a project plan. You may recognize it as what you get from Microsoft Project.

This is better called a project schedule, in that it shows when we expect the various sections of

the project to happen. We will see this later.

What we want to have in our project plan is:


6/124


Approach

6

1.Aim of project2.Outputs3.Quality criteria4.Resources5.Management structure6.Milestones7.Tolerances8.Dependencies9.Risks10.Schedule

Let's have a look at these in turn, and see why they are needed, and what we want to achieve with

each of them.

Aim of Project

What do we want to produce? The aim of the project is a mixture of the reasons for doing the

project and the benefits that are expected from it. This section of the plan can be either fulfilled

by linking to the main business case, or by restating it in language for the expected audience. For

example, your business case may have been written for high level approval in your organization.You may want to now put it in terms the project executive expects.

Outputs

Given the aim of the project, what do we actually need to produce to get there? What will your

completed project be made up of? These need to be clearly defined. For example, your project's

aim may be to upgrade the IT infrastructure in an organization. Your final output would be a

completed computer network, a new computer on every desk, and all appropriate software

installed and ready to go.

Quality Criteria

Now we have the outputs, we need to understand what quality they need to be of. In the example

above, we have an output of a completed computer network. However, we need to know that the

network can actually cope with the amount of traffic going over it.


7/124


Approach

7

This means we need the completed output to be of a certain quality, and we need to define what

that quality is. These targets tell you what success is, what completion of the project is. They need

to be SMART:

Specific: Clearly defined and precise. Measurable: e.g. not "new computers," but "computers with 2Gb of memory," etc. Attainable: Don't ask for the impossible. Relevant: Is the criterion actually related to the aim of the project? Time-based: Enough time to achieve this. There is no point expecting a year's worth of

work in one week!

It is important you take some time with the stakeholders in your project to produce this list. Thefinal customer of the project will naturally be very involved, but don't forget your business head -

don't promise everything without considering the costs. Your project executive, and a

representative of those who will be doing the work, will have major inputs into this also.

Finally, you will also need to decide who has the final say over the quality of the outputs.

Hopefully your work on defining the quality criteria will mean there are no arguments over the

quality (i.e. no qualitative judgments, only quantitative) but you need to make sure you schedule

in time and people to do the evaluation work.

Resources

We have now set down what outputs we need to produce, and what quality they need to be at.

This means we are now in a position to look at the resources we will need to achieve this.

Resources include staff time, particular knowledge or skill sets, money (e.g. buying equipment),

and time (some tasks can't be increased by throwing more people at the problem, e.g. delivery

times, setting time for concrete, etc.).

Management Structure

How are we going to manage the work? You need to describe the general approach to the projecthere. Who will be the decision makers for the various different streams of work? For example,

you may be doing a significant procurement - who makes the decision about what company to

buy from?

How will we share progress on the project? Who will we share it to? For example, you may

decide to have regular project team meetings - who needs to attend? What level of information


8/124


Approach

8

will you be sharing? Who else needs to be kept informed, at what level of detail, and how often?

For example, you may want to keep the project executive updated at an overview level of detail

on a weekly basis, while you keep other managers appraised at a higher level of detail.

You will also need to spell out the relationship of yourself to the project executive, in terms of the

monitoring of progress. Equally, you need to put down how you will be monitoring progress of

the allocated tasks.

There is no one right answer for how this should be done, and indeed it will vary with every

project. Make sure you think about the size and complexity of the project, and also the

organisation's ethos and current management style.

Milestones

Here you need to think about how you will break up the project. Unless it is very small, you don't

want to have the entire project as one lump of work, with the only check on progress at the veryend. Instead, it makes sense to break the project up into discrete chunks, where related tasks can

be lumped together, with a sensible milestone at the end of them. For example, in the technology

refresh in the example above, you may want to break the project down into something like:

1.Requirements Gathering2.Tender Writing3.Tendering Process4.Contract Negotiation5.Deployment6.Testing

It makes sense to have a defined milestone, so you know when each section is completed. There

is also another benefit of breaking the project into chunks, which I'll come back to.

Tolerances

You will have already looked at the resources you need. Now we need to set how far you, or the

project executive, can let the project stray from these targets before needing to sound the alarm.

For example, you could set a tolerance in terms of finance of +/- 5%, and a tolerance in terms of

time of +/- 10%. Equally, you may want to look at tolerances of quality - i.e. how far from the

quality criteria are you willing to accept?


9/124


Approach

9

It is remarkably unlikely that a project will not deviate from its resource or quality targets. Setting

tolerances allows you to be able to manage the project without continually seeking guidance from

the project executive as to whether you should carry on. This is not to say that you should be

happy with these deviations, and you should try to avoid them, and monitor them closely. That

way you can build your understanding of the project for the future.

Dependencies

This is where you look at what needs to happen before something else. For example, in our

example above, you need to complete the requirements gathering before you can finish the tender

documentation. You need to start thinking about the dependencies so you, and the project team,

can understand the impact of changes in any part of the project.

These dependencies should include both those internal to the project (i.e. those under your

control), and those external to it (i.e. those outside of your control). For example, you may need

an accurate figure for the number of staff in the organisation. This needs to come from your HR

department, and would be an external dependency.

Risks

Simply, what could go wrong? What could happen that would damage your ability to deliver the

project? Are there things you can do to avoid them, or minimise them ?

Scheduling

This is the Gantt chart-style information that many people envisage when a project plan is

mentioned. In this, you need to put down what you expect to happen when. It will include your

dependencies, milestones, and probably resources. At this point, it will be a relatively high

overview of the whole project.

One needs to understand that you cannot make a perfect schedule. , what you need to do here is

achieve the possible.

The schedule needs to include the overview, with the project broken down into sensible chunks.

This is the other advantage of breaking the project into chunks we mentioned above. By having

the project broken up in this way, you will be able to start planning the first section in quite some

detail, extending out for a few weeks. But from then on, it will start to be based more and more

on blind guesswork and faith. Do not try to be artificially precise - keep it vague, use rough

figures.


10/124


Approach

10

As you come to the end of each chunk of the project, you will be able to plan the next one. You

can use the information and experience you have just gained from the previous section, and thus

you will be able to be more confident.

Make sure you explain this to your project stakeholders! Often your project executive may look at

a schedule, and imagine everything is laid out and known. You must get this idea out of their

head straight away! Explain that the early part is firmer than the rest, and make sure they expect

changes as the project moves on.

The planner will crave certainty, and absolute dates for the project, from the very beginning. You

must resist the pressure to name a specific date, and explain why. While there may be a

temptation to give an answer, One needs instead be realistic about what is and isn't possible in

terms of scheduling. Anything else can only lead to trouble for you, the project, and ultimately

the planner will further down the line.

The Purpose of WBS:

A deliverable oriented hierarchical decomposition of the work to be executed by a project

team to accomplish the project objectives to create the required deliverables .

What purpose does WBS serve to our project and our project team. There are three reasons to

use a WBS in your projects .The first is that it helps more accurately and specifically define

and organize the scope of the total project .The most common way this is done by using a

hierarchical tree structure .Each level of this structure breaks the project deliverables or

objectives down to more measurable chunks .

Second reason for using WBS in your projects is to help with assigning responsibilities,

resource allocation, monitoring the project and controlling the project .The WBS makes the

deliverables more precise and concrete so that the project team knows exactly what has to be

accomplished within each deliverable .This also allows for better estimating of cost, risk and

time because you can work from smaller task. back upto the level of entire project . Thirdly,

It allows you to double check all the deliverables specifics with the stake holder and make

sure there is nothing missing or overlapping.


11/124


Approach

11

1.Process: After creating WBS to help our project efficiency & effectiveness .there areseveral inputs you will need to get you off on high foot.

The project Scope statement.The project Scope management.Organizational process assetsApprove change requests (PMBOK guide)

Ones team needs to create WBS along with these inputs yo will use certain tools as well :

Work break down templates.Decomposition (PMBOK)Using tools you will create the following outputs

Work breakdown Structure.WBS dictionary Project Scope Statement (Updates on Primavera tool ) Project Scope management Plan (updates)Requested changes-PMBOK (guide)

The first step to creating your WBS is to get all your team, and possibly key stakeholders,

together in one room. Although your team is not listed as an input or tool in the above

sections, they are probably your most vital asset to this process. Although your team

possesses all the expertise, experience, and creative thinking that will be needed to get down

to the specifics of each deliverable. Next, we have to get the first two levels setup. The first

level is the project title, and the second level is made up of all the deliverables for the project.

At this stage it is important to function under the 100% Rule. This rule basically states that

the WBS (specifically the first two levels) includes 100% of all the work defined in theproject scope statement and management plan. Also, it must capture 100% of all the

deliverables for the project including internal, external, and interim. In reality the WBS

usually only captures between 90-95%, and 100% is our goal.

Once we have got the first two levels set, it is time to launch into our decomposition.

Decomposition is the act of breaking down deliverables in to successively smaller chunks of


12/124


Approach

12

work to be completed in order to achieve a level of work that can be both realistically

managed by the project manager and completed within a given time frame by one or more

team members. This level of breakdown and detail is called the work package. Work

packages are the lowest level of the WBS and are pieces of work that are specifically

assigned to one person or one team of people to be completed. This is also the level at which

the project manager has to monitor all project work. Now the million dollar question is how

specific and small does a chunk of work need to be to still be considered a work package?

Well PMBOK does not seem to give a definitive answer on that. Most project managers

concur that this varies by project, but can usually be measured using the 8/80 Rule. The 8/80

Rule says that no work package should be less than 8 hours or greater than 80 hours. Notice

we said that the work package is the lowest level of the WBS. Activities and tasks are not

included in the WBS. They will be planned from the work packages once they are assigned.

Occasionally, you will run into a project that is a "first of its kind," but that is not usually the

case. Most of the time, you, your team, or your organization has done a project like this one

in the past. That means that there should be a WBS from the previous project that you can use

as a template. This will save you a lot time and effort. Even if you have not done a project

like this one before, most Project Management Offices (PMOs) have basic WBS templates

that can get you started. Another great technique to make your life easier is the Post-It Note

Technique. , it actually works very well. In this technique you simply write each deliverable

on a post-it note and stick them at the top of a wall. Then you and your team start to break

down each deliverable into components and write each component on its own post-it note.

This way, as you place them on the wall and start to create your tree structure, everyone can

easily see what has been accomplished and where you are headed. Also this technique allows

for easy movement of components around within the WBS.

You can use your newly created WBS to look for missing or overlapping pieces of each

deliverable. This will help eliminate change requests and double work down the road. Once

that is completed, put your WBS on paper and log it into your project.

Many projects will also find it necessary to create a WBS Dictionary to accompany their

WBS. The WBS Dictionary is simply a document that describes each component in the WBS.

This helps clarify any specifics later on when team members completing the work or

stakeholders viewing the deliverables have questions. Also, when creating the WBS for very

large, lengthy, or complex projects, all the deliverables' specifics might not be known up

front and, therefore, it is difficult to create a full WBS. In cases such as these many people


13/124


Approach

13

use what is called Rolling Wave Planning. This is when you plan down to the level of detail

currently known and go back to plan deeper once more information is acquired. Usually

rolling wave planning needs to stay as least 2-3 months ahead of the actual work being done,

but of course this varies slightly by industry.

Pitfalls: Five commonly occurring Pitfalls

1. Level of Work Package Detail

When deciding how specific and detailed to make your work packages, you must be careful

to not get too detailed. This will lead to the project manager to have to micromanage the

project and eventually slow down project progress. On the other hand, work packages whose

details are too broad or large become impossible for the project manager to manage as a

whole.

2. Deliverables Not Activities or Tasks

The WBS should contain a list of broken down deliverables. In other words, what the

customer/stakeholder will get when the project is complete. It is NOT a list of specific

activities and tasks used to accomplish the deliverables. How the work is completed (tasks

and activities) can vary and change throughout the project, but deliverables cannot without a

change request, so you do not want to list activities and tasks in the WBS.

3. WBS is not a Plan or Schedule

The WBS cannot be used as a replacement for the project plan or schedule. A WBS is not

required to be created in any type of order or sequence. It is simply a visual breakdown of

deliverables.

4. WBS Updates Require Change Control

The WBS is a formal project document, and any changes to it require the use of the project

change control process. Any changes to the WBS change the deliverables and, therefore, the

scope of the project. This is an important point to help control scope creep.

5. WBS is not an Organisational Hierarchy

The WBS and Organisational Hierarchy chart are never the same thing. Although often

similar in appearance, these two documents are very different. The Organisational Hierarchy

shows things like chain of command and lines of communication, but the WBS is restricted

simply to a project and shows only the deliverables and scope of that project.


14/124


Approach

14

The WBS is an extremely valuable tool to the project management methodology. It can make

or break a project. It sets the foundation for the rest of the project planning. A solid WBS

helps ensure proper project baselines, estimating, resource use, scheduling, risk analysis, and

procurement

Gantt charts and PERT charts are useful tools for visualizing and communicating information

about projects, but they have a number of limitations. In addition, the ease with which they

can be created using software applications makes them open to misuse and misinterpretation.

Project Breakdown

Part of the problem is that there isn't a clear understanding of how to break the project down

in the first place, and using Gantt chart software to do this isn't necessarily the best way of

going about it.

A common method of breaking a project down is using a Work Breakdown Structure (WBS).

This concentrates on analyzing the scope of the project according to its outcomes or

deliverables. This method of breakdown does not necessarily imply any dependencies (logic)

or sequence, hence neither the Gantt chart nor the PERT chart are suitable tools for carrying

out this analysis.

Project Management Methodologies such as PRINCE2 also seek to analyze the project in

terms of deliverables, "Products," although there is more of a sequence involved in thedefinition of the stages: in particular, there is a process of sign-off for each stage, sometimes

called "Gateways", before the project is allowed to move on to the next.

Using the Charts

Having defined the breakdown, you should have a list of tasks which need to be completed in

order to produce the desired outcomes. These tasks will have dependencies and durations and

hence can be scheduled. Now's the time for the PERT or network chart software to be used.

You can concentrate on the logic of the task relationships: the software should do the

scheduling for you, including calculating the critical path.

Once the logic has been defined and the schedule has been calculated, the result can be

displayed on the Gantt chart. It's often best not to show the dependencies (links) on this chart,

especially if there are a large number of tasks and complex dependencies between them. It's

also helpful if you can produce separate Gantt Charts for different WBS levels or


15/124


Approach

15

stages/products, as they will have fewer tasks in them. Summary Gantt charts showing higher

levels in the WBS may also be useful.

Updating Progress

Charts should be seen as snapshots of the current project situation: they should be dynamicand change as circumstances change, particularly as work is carried out on the tasks.

I've seen a number of cases where the project manager creates a beautiful Gantt chart

showing the project being completed on time, with nice neat task relationships, sends it out to

all the people involved - and then they sit back and leave it at that. When asked how the

project is going, they say "fine" because the chart looks fine. What they fail to do is update it

with what's actually happening and re-schedule it according to real progress.

If some tasks are taking longer than expected, are they going to continue at the same pace and

if so, what impact will this have on the rest of the plan? Remaining effort needs to be

estimated and the project rescheduled.

What will be the effect if some tasks are ahead of schedule? The impact on resources will not

be apparent from just looking at the charts: other tools are needed, such as resource

histograms, to identify peaks and troughs in resource utilisation.

Building SMART goals.

Once you have planned your project, turn your attention to developing several goals that will

enable you to be successful. Goals should be SMART - specific, measurable, agreed upon,

realistic and time-based.

A goal might be to hold a weekly project meeting with the key members of your team or to

organize and run a continuous test programme throughout the project.

The acronym SMART has a number of slightly different variations, which can be used to

provide a more comprehensive definition for goal setting:

S - Specific, significant, stretching

M - Measurable, meaningful, motivational

A - agreed upon, attainable, achievable, acceptable, action-oriented

R - realistic, relevant, reasonable, rewarding, results-oriented


16/124


Approach

16

T - time-based, timely, tangible, trackable

This provides a broader definition that will help you to be successful in both your business

and personal life.

When you next run a project take a moment to consider whether your goals are SMART

goals.

SMART Goals

Specific

Well defined

Clear to anyone that has a basic knowledge of the project

Measurable

Know if the goal is obtainable and how far away completion is

Know when it has been achieved

Agreed Upon

Agreement with all the stakeholders what the goals should beRealistic

Within the availability of resources, knowledge and time

Time Based

Enough time to achieve the goal

Not too much time, which can affect project performance


17/124


Approach

17

Literature review

A Project Management Primer Basic principles- Scope triangle

Called the Scope triangle or the Quality trianglethis shows the tradeoffs inherent in any

project.

The triangle illustrates the relationship between three primary forces in project .Time is the

available time to deliver the project. Cost represents the amount of money or resources

available. Quality represents the fit-topurpose that the project must achieve to be success.

The normal situation is that that one of the factor is fixed and the other two will vary inverse

proportion to each other .For e.g. Time is often fixed and Quality of the end product will

depend on the cost or resource available .Similarly if you are working on a fixed quality then

cost of the product will depend on the time available (if you have longer you can d it with

fewer people).

The astute person will be wondering what will happen when two of the things are fixed. This

will happen when costs are fixed and project has a delivery date to deliver, an all to set of

familiar set of circumstances.

Cost

Time

Quality


18/124


Approach

18

Then if the scope starts to creep you are left with only one choice cut on functionality.

Cutting functionality may seem to be extreme measure, but an experienced Project manager

will happily cut away functionality as if like peeling a potato.As long as the

Core requirements remain, everything will be fine.

A really experienced project manager might even pad his project while his superfluous

functionality that can be sacrificed when the crunch comes.

A phenomenon known as scope creep can be linked to the triangle too, Scope creep is

almost unstoppable tendency to accumulate a new functionality .Some scope creep is

inevitable since, early on , your projects will be poorly defined and will need to evolve .A

large amount of scope creep can be disastrous .

When a scope starts to creep, new functionality must be added to cover the increased scope

.This is represented by the quality arm of the triangle, representing the ability of the product

to fulfill users requirements .More requirements =a better quality products.

In this situation you have, three questions

Add time delay the project to give you an add the functionality.Add cost recruit ,hire or acquire more people to do the extra work.Cut Quality to trade off some non essentials requirements

If the art of management lies in making decisions, then the art of Project Management lies in

quick decision making.

The Context of Project Failure

There are a number of increasingly popular project management methodologies aimed at

standardizing project management approaches, reducing project risk, and guarding against project

failure. The three main accreditations - all of which have spawned subsidiary industries in

training, certification, and consultancy, are as follows:

PRINCE2 (Projects In Controlled Environments)

MSP (Managing Successful Programmes) both MSP and PRINCE2 originating from the

Office of Government Commerce in the UK


19/124


Approach

19

The Project Management Professional (PMP) certification administered by the Project

Management Institute in the US

To put project failure in context; Gartner, the world's most listened to analyst firm estimate

that 66% of large scale projects fail to achieve their stated business objectives, are delivered

late, or are substantially over budget.

The Standish Group, which exists solely to track IT successes and failures, defines project

failure as projects abandoned midstream, and estimates failure rate at 15 percent, but that

"challenged" projects (defined as projects with cost overruns, time overruns, and projects not

supportable as delivered) represent 51% of all IT projects.

Looking at these figures in the post PRINCE2 / MSP / PMP world, you might be forgiven for

asking yourself, "why then is project success so elusive?"

The Standish Group believes that the most important factors in a project's success or failureare, in order of importance:

The degree of user involvement Executive management support An experienced project managerThere are probably few who would disagree with the points above, which all deal with the

question, "how are we going to manage this project through its active life?"

Poorly defined deliverables and scope, lack of organizational buy-in, poor resource allocation

and control of risk, poor project management, components that are not fit for purpose, and so

on - any and all of these can cause project failure.

But what about the failing projects that should never have seen the light of day?

First Things First

.

The second of Stephen Covey's famed 7 Habits of Highly Effective People is "begin with the

end in mind," which is an excellent guiding principle for project management approval as it is

for life: if you don't define what you want to achieve, it's very unlikely that you'll do so. In

consultant-speak, this is usually couched in the question, "what does success look like?"

A broad aim is fine to start with:


20/124


Approach

20

We want to provide world-class services to our clients

We want to reduce the number of outages affecting our systems

We want to take a higher proportion of payments online

We want to increase customer satisfaction

But these need to be much more tightly defined in terms of why, what, how, when, and who,

in order to establish the capability of the organisation to deliver them, the impact on the

business and probable pain level involved in change management, the likely cost

implications, and a best guess at the timescales involved.

This becomes a project charter, or project brief, or in PRINCE2 terms, the Project Initiation

Document (PID), which can then be realistically and robustly challenged by the potential

stakeholders, refined and re-issued, so that everyone knows where they're going, how they're

getting there, when they're supposed to arrive, and what the organisation will look like when

the project ends.

1.Speaking to many of my project management colleagues, and reading the industry press,it's clear that most projects do not start with this level of definition, and poor project

definition stems from what I believe is the main cause of project failure from the

approval stage onwards.

An insufficient level of accountability and responsibility at an appropriately senior level for

the success of a project, through its lifecycle.

Take a moment to think through the project failures you've known, and ask the following

questions:

Who was responsible for the success of the project? Were there any consequences for the failure of the project?If the answers are in any way vague, it would suggest that the senior members of the

organisation in question need to look seriously at the way in which projects are

commissioned.

Senior people are busy people, and tend to focus attention where attention is required. If there

are no consequences for project failure, of non-attendance at Project Boards, or lack of

preparation for them, or if Project Board members are insufficiently senior or influential, the


21/124


Approach

21

Board doesn't function. If there is no customer driving a project, or at least heavily engaged

with it, the chances are that it will fail.

The Road Map

There is always too much pressure on organisations to take on too many projects, and senior

managers as well as project staff, are always spread too thin: managing competing interests

and resources is invariably a delicate balancing act.

With this in mind, the following approach will help to ensure that a project starts off on the

right foot, whatever befalls it later on:

2.Sit down with the organisation's project customers and hammer out an agreement onproject prioritization, based on business requirement, business risk, available resources,

and so on

3.Publish the list of projects and their priorities and go through another iteration of theexercise if necessary so that everyone can feel that they've had their say

4.Close the projects on the bottom half of the list - if they're already low priority, you'resaving time and trouble stopping them at this stage

5.From the projects within the context of the current organisation. Cut the projects thatdon't - you can always revisit them later that remain, identify those that have strong

customer (in every sense) commitment, clearly identifiable purpose, and those that can be

achieved

6.Agree senior owners for the projects still in the game, making it clear that they will beclosely identified with the project(s) they own, will be required to drive the project

forward, and will lose credibility if it fails. If a senior owner (seniority being relative to

the ambition of the project) cannot be found for a project, cut it

7.You should be left with a handful of projects left that are important to the organisation,with senior commitment, sufficient resources (freed from the projects that aren't goingahead) and have a high chance of success

8.There may be little appetite in your organisation for the effort that such a rigorousapproach implies, but if you look at how much project failure has cost the organisation

over the years, it's much less effort than struggling to undertake every project, then going

before the Chief Exec to explain why you haven't delivered.


22/124


Approach

22

Define the Scope and Objectives

9.Firstly, understand the project objectives. To make a company profile? Or to make asmall business plan .Deciding the real objectives will help you plan the project.

10.Scope defines the boundary of the project. Is the organisation of transport to take staff tothe blood bank within scope? Or, should staff make their own way there? Deciding what's

in or out of scope will determine the amount of work which needs performing.

11.Understand who the stakeholders are, what they expect to be delivered and enlist theirsupport. Once you've defined the scope and objectives, get the stakeholders to review and

agree to them.

Define the Deliverables

You must define what will be delivered by the project. If your project is an advertising

campaign for a new chocolate bar, then one deliverable might be the artwork for an

advertisement. So, decide what tangible things will be delivered and document them in

enough detail to enable someone else to produce them correctly and effectively.

Key stakeholders must review the definition of deliverables and must agree they accurately

reflect what must be delivered.

Project Planning

Planning requires that the project manager decides which people, resources and budget are

required to complete the project.

You must define what activities are required to produce the deliverables using techniques

such as Work Breakdown Structures. You must estimate the time andeffort required for each

activity, dependencies between activities and decide a realistic schedule to complete them.

Involve the project team in estimating how long activities will take. Set milestones which

indicate critical dates during the project. Write this into the project plan. Get the key

stakeholders to review and agree to the plan.


23/124


Approach

23

Communication

1.Project plans are useless unless they've been communicated effectively to the projectteam. Every team member needs to know their responsibilities. I once worked on aproject where the project manager sat in his office surrounded by huge paper schedules.

The problem was, nobody on his team knew what the tasks and milestones were because

he hadn't shared the plan with them. The project hit all kinds of problems with people

doing activities which they deemed important rather than doing the activities assigned by

the project manager.

Tracking and Reporting Project Progress

Once your project is underway you must monitor and compare the actual progress with the

planned progress. You will need progress reports from project team members. You should

record variations between the actual and planned cost, schedule and scope. You should report

variations to your manager and key stakeholders and take corrective actions if variations get

too large.

You can adjust the plan in many ways to get the project back on track but you will always

end up juggling cost, scope and schedule. If the project manager changes one of these, then

one or both of the other elements will inevitably need changing. It is juggling these three

elements - known as the project triangle - that typically causes a project manager the most

headaches!

Change Management

Stakeholders often change their mind about what must be delivered. Sometimes the business

environment changes after the project starts, so assumptions made at the beginning of the

project may no longer be valid. This often means the scope or deliverables of the project need

changing. If a project manager accepted all changes into the project, the project would

inevitably go over budget, be late and might never be completed.

By managing changes, the project manager can make decisions about whether or not to

incorporate the changes immediately or in the future, or to reject them. This increases the

chances of project success because the project manager controls how the changes are

incorporated can allocate resources accordingly and can plan when and how the changes are

made. Not managing changes effectively is often a reason why projects fail.


24/124


Approach

24

Risk Management

2.Risks are events which can adversely affect the successful outcome of the project. I'veworked to avoid the risk, or, if the risk cannot be avoided, to mitigate the risk to lessen its

impact if it occurs. This is known as risk management.

You don't manage all risks because there could be too many and not all risks have the

same impact. So, identify all risks, estimate the likelihood of each risk occurring (1 = not

likely, 2 = maybe likely, 3 = very likely). Estimate its impact on the project (1 - low, 2 -

medium, 3 - high), then multiply the two numbers together to give the risk factor. High risk

factors indicate the severest risks. Manage the ten with the highest risk factors. Constantly

review risks and lookout for new ones since they have a habit of occurring at any moment.on

projects where risks have included: staff lacking the technical skills to perform the work,

hardware not being delivered on time, the control room at risk of flooding and many others.

Risks will vary for each project but the main risks to a project must be identified as soon as

possible. Plans must be made

Not managing risks effectively is a common reason why projects fail.

Summary

Following these best practices cannot guarantee a successful project but they will provide abetter chance of success. Disregarding these best practices will almost certainly lead to

project failure.

The benefits of risk management in projects are huge. You can gain a lot of money if you

deal with uncertain project events in a proactive manner. The result will be that you minimise

the impact of project threats and seize the opportunities that occur. This allows you to deliver

your project on time, on budget and with the quality results your project sponsor demands.

Also your team members will be much happier if they do not enter a "fire fighting" mode

needed to repair the failures that could have been prevented.

Rule 1: Make Risk Management Part of Your Project

The first rule is essential to the success of project risk management. If you don't truly embed

risk management in your project, you can not reap the full benefits of this approach. You can


25/124


Approach

25

encounter a number of faulty approaches in companies. Some projects use no approach

whatsoever to risk management. They are either ignorant, running their first project or they

are somehow confident that no risks will occur in their project (which of course will happen).

Some people blindly trust the project manager, especially if he (usually it is a man) looks like

a battered army veteran who has been in the trenches for the last two decades. Professional

companies make risk management part of their day to day operations and include it in project

meetings and the training of staff.

Rule 2: Identify Risks Early in Your Project

The first step in project risk management is to identify the risks that are present in your

project. This requires an open mind set that focuses on future scenarios that may occur. Two

main sources exist to identify risks, people and paper. People are your team members that

each bring along their personal experiences and expertise. Other people to talk to are expertsoutside your project that have a track record with the type of project or work you are facing.

They can reveal some booby traps you will encounter or some golden opportunities that may

not have crossed your mind. Interviews and team sessions (risk brainstorming) are the

common methods to discover the risks people know. Paper is a different story. Projects tend

to generate a significant number of (electronic) documents that contain project risks.

They may not always have that name, but someone who reads carefully (between the

lines) will find them. The project plan, business case and resource planning are good starters.

Another categories are old project plans.

Are you able to identify all project risks before they occur? Probably not. However if you

combine a number of different identification methods, you are likely to find the large

majority. If you deal with them properly, you have enough time left for the unexpected risks

that take place.

Rule 3: Communicate About Risks

Failed projects show that project managers in such projects were frequently unaware of the

big hammer that was about to hit them. The frightening finding was that frequently someone

of the project organization actually did see that hammer, but didn't inform the project

manager of its existence. If you don't want this to happen in your project, you better pay

attention to risk communication.

A good approach is to consistently include risk communication in the tasks you carry out. If

you have a team meeting, make project risks part of the default agenda (and not the final item


26/124


Approach

26

on the list!). This shows risks are important to the project manager and gives team members a

"natural moment" to discuss them and report new ones.

Another important line of communication is that of the project manager and project sponsor

or principal. Focus your communication efforts on the big risks here and make sure you don't

surprise the boss or the customer. Also take care that the sponsor makes decisions on the top

risks, because usually some of them exceed the mandate of the project manager.

Rule 4: Consider Both Threats and Opportunities

3.Project risks have a negative connotation: they are the "bad guys" that can harmyour project. However modern risk approaches also focus on positive risks, the

project opportunities. These are the uncertain events that beneficial to your project

and organization. These "good guys" make your project faster, better and more

profitable.

4.Unfortunately, lots of project teams struggle to cross the finish line, beingoverloaded with work that needs to be done quickly. This creates project

dynamics where only negative risks matter (if the team considers any risks at all).

Make sure you create some time to deal with the opportunities in your project,

even if it is only half an hour. Chances are that you see a couple of opportunities

with a high pay-off that don't require a big investment in time or resources.

Rule 5: Clarify Ownership Issues

Some project managers think they are done once they have created a list with risks. However

this is only a starting point. The next step is to make clear who is responsible for what risk!

Someone has to feel the heat if a risk is not taken care of properly. The trick is simple: assign

a risk owner for each risk that you have found. The risk owner is the person in your team that

has the responsibility to optimize this risk for the project. The effects are really positive. At

first people usually feel uncomfortable that they are actually responsible for certain risks, but

as time passes they will act and carry out tasks to decrease threats and enhance opportunities.

Ownership also exists on another level. If a project threat occurs, someone has to pay the bill.

This sounds logical, but it is an issue you have to address before a risk occurs. Especially if

different business units, departments and suppliers are involved in your project, it becomes

important who bears the consequences and has to empty his wallet. An important side effect

of clarifying the ownership of risk effects, is that line managers start to pay attention to a


27/124


Approach

27

project, especially when a lot of money is at stake. The ownership issue is equally important

with project opportunities. Fights over (unexpected) revenues can become a long-term

pastime of management.

Rule 6: Prioritise Risks

Some risks have a higher impact than others. Therefore, you better spend your time on the

risks that can cause the biggest losses and gains. Check if you have any showstoppers in your

project that could derail your project. If so, these are your number 1 priority. The other risks

can be prioritized on gut feeling or, more objectively, on a set of criteria. The criteria most

project teams use is to consider the effects of a risk and the likelihood that it will occur.

Whatever prioritization measure you use, use it consistently and focus on the big risks.

Rule 7: Analyze Risks

Understanding the nature of a risk is a precondition for a good response. Therefore take some

time to have a closer look at individual risks and don't jump to conclusions without knowing

what a risk is about.

Risk analysis occurs at different levels. If you want to understand a risk at an individual level

it is most fruitful to think about the effects that it has and the causes that can make it happen.

Looking at the effects, you can describe what effects take place immediately after a risk

occurs and what effects happen as a result of the primary effects or because time elapses. A

more detailed analysis may show the order of magnitude effect in a certain effect category

like costs, lead time or product quality. Another angle to look at risks, is to focus on the

events that precede a risk occurrence, the risk causes. List the different causes and the

circumstances that decrease or increase the likelihood.

Another level of risk analysis is investigate the entire project. Each project manager needs to

answer the usual questions about the total budget needed or the date the project will finish. If

you take risks into account, you can do a simulation to show your project sponsor how likely

it is that you finish on a given date or within a certain time frame. A similar exercise can be

done for project costs.

The information you gather in a risk analysis will provide valuable insights in your project

and the necessary input to find effective responses to optimize the risks.


28/124


Approach

28

Rule 8: Plan and Implement Risk Responses

Implementing a risk response is the activity that actually adds value to your project. You

prevent a threat occurring or minimise negative effects. Execution is key here. The other rules

have helped you to map, prioritise and understand risks. This will help you to make a sound

risk response plan that focuses on the big wins.

If you deal with threats you basically have three options, risk avoidance, risk minimization

and risk acceptance. Avoiding risks means you organise your project in such a way that you

don't encounter a risk anymore. This could mean changing supplier or adopting a different

technology or, if you deal with a fatal risk, terminating a project. Spending more money on a

doomed project is a bad investment.

The biggest category of responses are the ones to minimise risks. You can try to prevent a

risk occurring by influencing the causes or decreasing the negative effects that could result. Ifyou have carried out properly risk analysis you will have plenty of opportunities to influence

it. A final response is to accept a risk. This is a good choice if the effects on the project are

minimal or the possibilities to influence it prove to be very difficult, time consuming or

relatively expensive. Just make sure that it is a conscious choice to accept a certain risk.

Responses for risk opportunities are the reverse of the ones for threats. They will focus on

seeking risks, maximizing them or ignoring them (if opportunities prove to be too small).

Rule 9: Register Project Risks

This rule is about bookkeeping. Maintaining a risk log enables you to view progress and

make sure that you won't forget a risk or two. It is also a perfect communication tool that

informs your team members and stakeholders.

A good risk log contains risks descriptions, clarifies ownership issues and enables you to

carry our some basic analyses with regard to causes and effects. Most project managers aren't

really fond of administrative tasks, but doing your bookkeeping with regards to risks pays off,

especially if the number of risks is large. Some project managers don't want to record risks,because they feel this makes it easier to blame them in case things go wrong. However the

reverse is true. If you record project risks and the effective responses you have implemented,

you create a track record that no one can deny. Even if a risk happens that derails the project.

Doing projects is taking risks.


29/124


Approach

29

Rule 10: Track Risks and Associated Tasks

The risk register you have created , will help you to track risks and their associated tasks.

Tracking tasks is a day-to-day job for each project manager. Integrating risk tasks into that

daily routine is the easiest solution. Risk tasks may be carried out to identify or analyse risks

or to generate, select and implement responses.

Tracking risks differs from tracking tasks. It focuses on the current situation of risks. Which

risks are more likely to happen? Has the relative importance of risks changed? Answering

this questions will help to pay attention to the risks that matter most for your p roject value.

The 10 golden risk rules above give you guidelines on how to implement risk management

successfully in your project. However, keep in mind that you can always improve. Therefore

rule number 11 would be to use the Japanese Kaizen approach: measure the effects of your

risk management efforts and continuously implement improvements to make it even better.

Success with your project!

The Risky Business of Project Management

Undertaking any project, whether in-house or in partnership with a professional services firm,

entails risk. Project risk is defined as any area of concern that could prevent a project from

achieving all of its benefits. Project risk requires careful management and involves

identification, assessment, and mitigation.

It is important at the beginning of any project to go through the risk identification process.Not all project risks are obvious. When identifying risks, look for areas in the project that are

based on:

1.Insufficient or unreliable data2.Insufficient preparation3.Inadequate resources4.Lack of control

Some areas to pay close attention to are:

Requirements identification Involvement of project sponsorship


30/124


Approach

30

Level of project management experience Third-party involvement Political/cultural environment Change control procedures and management Complexity of the technologyRisk identification is only the first step. Risks need to be assessed to quantify and prioritise

them according to their impact on the project. Keep in mind significant professional judgment

is required during the assessment process to quantify the magnitude of potential negative

impact and to develop risk control measures. The assessment process should determine the

(1) likelihood of the risk occurring, (2) range of outcomes, (3) estimated timing of the risk,

and (4) the frequency with which it will occur. It should also determine the warning signs of

the risk that will forecast that the occurrence of the risk is imminent. The prioritised risks

provide the basis for establishing Project Success Factors (PSFs). Specific action plans are

developed to address each PSF. For example, assume that required key policy changes are a

high risk. An action plan must be developed to:

Focus on thorough and frequent communications Implement a steering committee structure Obtain strong support for the project team from executive management Stress the benefits of the project Identify training needs earlyOnce risks have been identified and assessed, mitigation plans should be developed. The

plans document what the response will be when a risk event occurs. Keep in mind a

mitigation plan might be to do nothing to mitigate the risk. The need is to accept that a risk

exists and be prepared to deal with the consequences when and if it happens. This type of

action plan typically applies to low priority/minimal project impact risks. A mitigation plan

should outline plan B for the project area impacted by the risk. Knowing what plan B is prior

to having to execute it will greatly reduce the probability of increasing the negative impact of

the risk event or causing other unknown risks to occur.


31/124


Approach

31

An effective risk project management process means choosing and implementing risk-control

strategies that work. Identifying, assessing, and developing mitigation plans are not one-time

events. These processes need to occur throughout the life of the project. As the project

progresses and project risk changes occur, documentation resulting from the identification,

assessment, and mitigation planning processes need to be updated. The risk management

process must be continuous.

Requirements Management

A critical part of any project is the requirements management. If you are unsure about what is

going to be delivered how will you know when you get there?

What is User Requirements Capture?

User Requirements Capture is a research exercise that is undertaken early in a project lifecycle to

establish and qualify the scope of the project. The aim of the research is to understand the product

from a user's perspective, and to establish users' common needs and expectations. The user

requirements capture is useful for projects that have a lack of focus or to validate the existing

project scope. The research provides an independent user perspective when a project has been

created purely to fulfil a business need. The requirements capture findings are then used to

balance the business goals with the user needs to ensure the project is a success.

Reduce Project Risk in the Requirements Process

Gathering and managing requirements are important challenges in project management.

Projects succeed or fail due to poor requirements at any time throughout the project lifecycle.

The continuously evolving baseline of requirements needs to be managed effectively. The

project manager needs to assess and understand the uniqueness of the requirements gathering

process for his/her individual project.

The Elements of a Good Feasibility Study

In its simplest form, a Feasibility Study represents a definition of a problem or opportunity to

be studied, an analysis of the current mode of operation, a definition of requirements, an

evaluation of alternatives, and an agreed upon course of action. As such, the activities for

preparing a Feasibility Study are generic in nature and can be applied to any type of project,

be it for systems and software development, making an acquisition, or any other project.
http://www.projectsmart.co.uk/what-is-user-requirements-capture.htmlhttp://www.projectsmart.co.uk/reduce-project-risk-in-the-requirements-process.htmlhttp://www.projectsmart.co.uk/elements-of-a-good-feasibility-study.htmlhttp://www.projectsmart.co.uk/elements-of-a-good-feasibility-study.htmlhttp://www.projectsmart.co.uk/reduce-project-risk-in-the-requirements-process.htmlhttp://www.projectsmart.co.uk/what-is-user-requirements-capture.html


32/124


Approach

32

Project Requirement Needs For Success: Important Considerations

A company with poor requirements practices is just asking for over-budget costs and regular

failure, according to a new report by IAG Consulting. The report, entitled Business Analysis

Benchmark, examined 110 enterprise technology projects at 100 companies to determine just

how important project requirements really are.

Requirement Gathering

Requirement gathering is an essential part of any project and project management. Understanding

fully what a project will deliver is critical to its success. This may sound like common sense but

surprisingly it's an area that is often given far too little attention.

Unified Modeling Language (UML)

A key element of any project is understanding the customer requirements. This is where theUnified Modeling Language (UML) can help.

Reaping the Benefits of Good User Requirements with the Unified Modeling

Language (UML)

A critical part of any software development project is the requirements gathering. If you are

unclear about what is going to be delivered, how will you know when you get there? Good

user requirements lead to better estimates, improved customer satisfaction, reduced cost and a

shorter duration.

Project Management: Tips for Helping You Adopt A Process

The Rational Unified Process, Enterprise Unified Process, Agile Development

Methodologies, Unified Modeling Languages. They come in many names, complexities and

sizes but following one will help ensure success on your next project. This is not a detailed

overview of a formal process. Instead it provides an overview of the most critical components

common to each, as well as some tips on successfully deploying them.

Use Case Diagrams: A PM's View

Recently, I attended a class on managing requirements with Use Cases. It was aimed at

training business analysts and programmers to use Unified Modeling Language (UML) to

understand and communicate business requirements. As a project manager I found it both

enlightening and encouraging.
http://www.projectsmart.co.uk/project-requirement-needs-for-success.htmlhttp://www.projectsmart.co.uk/requirements-gathering.htmlhttp://www.projectsmart.co.uk/uml.htmlhttp://www.projectsmart.co.uk/benefits-of-good-user-requirements.htmlhttp://www.projectsmart.co.uk/benefits-of-good-user-requirements.htmlhttp://www.projectsmart.co.uk/project-management-adopt-a-process.htmlhttp://www.projectsmart.co.uk/project-management-adopt-a-process.htmlhttp://www.projectsmart.co.uk/project-management-adopt-a-process.htmlhttp://www.projectsmart.co.uk/use-case-diagrams-a-pm-view.htmlhttp://www.projectsmart.co.uk/use-case-diagrams-a-pm-view.htmlhttp://www.projectsmart.co.uk/project-management-adopt-a-process.htmlhttp://www.projectsmart.co.uk/benefits-of-good-user-requirements.htmlhttp://www.projectsmart.co.uk/benefits-of-good-user-requirements.htmlhttp://www.projectsmart.co.uk/uml.htmlhttp://www.projectsmart.co.uk/requirements-gathering.htmlhttp://www.projectsmart.co.uk/project-requirement-needs-for-success.html


33/124


Approach

33

Project Scheduling and Resource Levelling

We all know that in the real world we, as project managers, are given the finish date of the

project before they even have a chance to plan for it. This is a good reason why we need to

get better at scheduling our projects and leveling our finite resources.

Sure, there are tools that allow us to automate the process, but a tool is as good as the

knowledge of those who use it. All in all, project managers have a tool and a method by

which we create our project schedules. But, we all suffer from common mistakes such as

having the wrong dependencies, excessive constraints, and inadequate level of detail in the

WBS, estimates too granular or nonexistent, over allocated resources, etc. Ring a bell?

The tool that is most widely used is MS Project (MSP) & Primavera (Mostly Construction

projects in Middle East countries & USA)

Develop the WBS

Most organizations have a hierarchical structure to break down the work. Typically, it looks like

this: Stage, Phase, Task/Deliverable/Milestone. This is a way to organize and define the total

scope of the project by decomposing the work to be done into tasks that the project team can

execute and create the required deliverables. The tasks, deliverables or milestones are

components that can be scheduled, cost estimated, monitored and controlled.

USE OF PLANNING TOOL PRIMAVERA 6.0

GANTT CHART

To completely closethe lower layout andview only the data inthe top layout, click

the Show/HideBottom Layout

button.


34/124


Approach

34

In this sample layout, the top part of the window shows activity data in a

Gantt Chart, and the lower part of the window displays the Activity Detail

Customizing Displays

Most windows and dialog boxes include a Display ot Layout Options bar

at the top of the screen that contains commands that enable you tocustomize the current display. Click this bar to display a menu of the

commands available for that window or dialog box. You can also access

many of these commands from the view menu.

To hide or show moreof the information in

each pane, drag thehorizontal split bar

between the twolayouts.

Click the LayoutOptions bar to

display a menu ofthe options

available for theActivitieswindow.


35/124


Approach

35

Sample LayoutsThe sample database included with the module provides standard layouts that you can use with

your own projects.

To open a sample layout, first open one of the projects from the sample database or your own

database in the activities window, then choose view, layout open.

In this sample layout, you can view your project data based on the projects work bre akdown

structure (WBS)

In this sample layout,

you can view your

project data based on the

projects work

breakdown structure

(WBS)


36/124


Approach

36

Establish Dependencies

Dependencies are defined so that the work is executed in the proper order. Understand the

following task dependency types before you use them; incorrect dependencies will impact the

finish date of your schedule and create unnecessary constraints:

1.Mandatory (hard logic) - Inherent in the nature of the work being done. They ofteninvolve physical limitations i.e. a test case must be defined before testing.

2.Discretionary (soft/preferred/preferential logic) - Based on experience, desire orpreferences i.e. the team decides that they will create the user manual after the first round

of testing, although it is not necessary.

3.External - Based on needs or desires of a party outside the project i.e. the server must bepurchased before configuring.

A network diagram is used to show dependencies in a graphical form. MSP generates a network

diagram automatically.

Work is the number of labour units (usually expressed in hours, days or weeks) required to

complete a scheduled task. Estimation is equivalent to success. Duration is the total number of

work periods (usually expressed as days or weeks) required to complete a scheduled task. When

estimating, keep in mind the different task types:

1.Fixed units (MSP default) - Allows the schedule to calculate the finish date ASAP basedon resource availability.

2.Fixed duration - Used when the priority is to preserve duration. To complete work, assignresources as needed to satisfy the finish date, remember my comment about "knowing"

the finish date before we even plan?

3.Fixed work - Some project management systems that sit on top of MSP don't support thistype because of the effort driven nature of it and the unpredictable results it may create.

So, I have chosen to get used to not using it at all.


37/124


Approach

37

This is how task types work:

TaskType

Revise Duration Revise Work Revise Units

FixedUnits

Work is recalculated, andunits are fixed.

Duration is recalculated,and units are fixed.

Duration is recalculated,and work is fixed.

Fixed

DurationWork is recalculated, and

duration is fixed.Units is recalculated, and

duration is fixed.Work is recalculated,

and units are fixed.

Task constraint is the next item we need to look at when estimating. You must avoid using

moderate and inflexible types. Wrong constraints increase the project risk and extend the finish

date:

1.As late as possible (flexible; default) - For projects scheduled from the finish date.Schedules the latest possible start and finish dates for the task.

2.As soon as possible (flexible; default) - For projects scheduled from the start date.Schedules the earliest possible start and finish dates for the task.

3.Finish no earlier than (moderate; avoid) - For projects scheduled from the start date.Indicates the earliest possible date that the task can be completed, and the task cannot

finish any time before the specified date.

4.Finish no later than (moderate; avoid) - For projects scheduled from the finish date.Indicates the latest possible date that the task can be completed, and the task can be

finished on or before the specified date.

5.Start no earlier than (moderate; avoid) - For projects scheduled from the start date.Indicates the earliest possible date that the task can begin, and the task cannot start any

time before the specified date.

6.Start no later than (moderate; avoid) - For projects scheduled from the finish date.Indicates the latest possible date that the task can begin, and the task can start on or

before the specified date.

7.Must finish on (inflexible; avoid) - Indicates the exact date on which the task must finish.Other scheduling parameters such as task dependencies lead or lag time, and resource

levelling become secondary to this requirement.


38/124


Approach

38

8.Must start on (inflexible; avoid) - Indicates the exact date on which the task must begin.Other scheduling parameters such as task dependencies, lead or lag time, and resource

levelling become secondary to this requirement.

Assign Resources

Resources (typically human) are assigned to tasks, deliverables and milestones that need to be

executed. At the beginning of the project, when named resources are not known yet, roles are

assigned that can later be replaced with names i.e. the role of Analyst is assigned to a task during

project scheduling and is later replaced with John Doe when he is the analyst assigned to the task.

Level Resources

Helps in utilising resources consistently throughout the project. Ensures resources are not over

allocated. Helps the project manager avoid delays caused by bad allocations. Helps the project

manager identify and take advantage of unused times by analysing task dependencies. MSP can

automatically level resources based on resource calendar, task types, dependencies, and

constraints, however, I have yet to find a project manager that has felt comfortable with the way

MSP does it. I level resources manually via the Resource Usage view, but if you insist in using

the automatic feature of MSP, save a copy first. If you find resource conflicts (over or under

allocations) you could:

1.Delay certain tasks.2.Assign a different resource.3.Change task dependencies.4.Remove tasks.5.Add tasks (instead of using the MSP's split task functionality, which is not supported by

some project management systems i.e. Clarity).

Determine the Critical Path

Helps the project manager identify tasks that must be carefully monitored. The critical path is the

longest duration path through a network diagram and it is the shortest path to complete the

project. Knowing the project's critical path should be the goal of the scheduling process. MSP

calculates the critical path automatically and through the Gantt chart it shows what tasks are in it.

One thing to keep in mind is that as tasks are completed ahead or behind schedule the critical path


39/124


Approach

39

changes. Another is that there can be more than one critical path but this increases risk. If the

critical path takes your project's finish date way too far there are a couple of techniques that

project managers can use to compress the schedule:

1.Fast tracking - Perform critical path tasks in parallel that were originally plannedsequentially. It usually increases risk and often results in rework.

2.Crashing - Assign additional resources to critical path tasks while maintaining scope.Almost always results in increased costs.

As project managers, we forget a very important intangible: resource calendars affect project

scheduling. Public holidays or time off in a resource's calendar makes those days non-workdays

and therefore, MSP skips them altogether.

Earned Value management (EVM)is the measurement, monitoring and control of project

progress in terms of cost, time and scope against an agreed fully integrated baseline plan. It is a

proven process that provides strong benefits for the control of projects .It facilitates the

integration of project scope, time, and cost objectives and the establishment of baseline plan

which performance can be measured during the execution of the project..

EVM has the unique ability to combine measurement of work performance (completion of

planned work ) ,Schedule performance (behind or ahead of schedule),and cost performance

(below or above budget) within a single integrated methodology .Furthermore it provides a sound

basis for early problem identification ,corrective actions ,and management re-planning as required

.The use of EVM improves delivery of projects.

Basic concepts of EVM are:

All project steps earn value as work is completed The earned value (EV) can then be compared to actual costs and planned costs to

determine project performance and predict future performance trends.

Physical progress is measured in dollars, so schedule performance and cost performancecan be analyzed in the same terms.


40/124


Approach

40

Scheduling

Project scheduling is the art of planning dates for starting and completing activities and

milestones.

Critical Chain Project Management reduces project Lead time

In spite of the fact that project task durations are often conservatively estimated to begin with, the

presence of certain behaviours can cause them to increase. Critical Chain Project Management

and project scheduling eliminates these behaviours and reduces project lead times. Four

behaviours make project durations longer than necessary.

Useful Techniques to fine-Tune Your Project Schedule

One of the most common problems that project managers weep about is "unrealistic timelines," a

common consequence of clients having set their expectations too high even before the project

starts. Ironically, there are occurrences in the duration of a project when a staff is sitting idly,

waiting for a colleague to finish so he can start his own task. In this situation, does the project

manager shout foul and blame other people? Chances are, as a project manager, he needs to give

the project schedule a second look.

Project Scheduling And Resource Levelling

We all know that in the real world we, as project managers, are given the finish date of the project

before we even have a chance to plan for it. This is a good enough reason why we need to get

better at scheduling our projects and levellin

next generation project management systems -a quality approach

Documents