5073662 the Busy Persons Project Management Book

8/14/2019 5073662 the Busy Persons Project Management Book

1/81


2/81


3/81

Table of Contents

Cha pter 1. So wha t is so special about p rojects?

Chapter 2. Getting started

Cha pter 3. Wha t else to consider

Chapter 4. Different projects, different paths

Chapt er 5. Fina lising th e plan s

Chapt er 6. Keeping it together

Cha pter 7. Well, how did you go?

Chapter 8. Additional tips for travellers

Appendices

A. Glossary of term s

B. C ool R eferences

C. Project sam ple form s


4/81


5/81

Page 5

Camille and I had a bit of a debate about what this should be called. Ithought of calling it T he Comp lete Idiot an d Du m m ies Guid e to Project

Management but, apart from being a bit demeaning, calling this book aDumm ies or Idiots Guide misses t he point th at project ma na gement can onlybe done by sma rt , clever a nd n on-dum mie people.

This book has been developed for people involved in projects of all types inorganisations. Most organisations are undergoing the changes that seem tobe coming faster and faster and are looking for projects and project managersto be key change agents. We want to thank Bob Kershaw whose vision andunderstanding of the importance of business people becoming projectma na gers ma de th is book possible.

As a rule of thumb, the types of projects we are talking about would involveup t o five people working u p t o three m ont hs. Pr ojects larger t ha n t his wouldneed to use the same principles but there are additional procedures such asformal risk modelling and project documentation that would be required. Wecover these in our other book for not so busy people - Third Wave Project

Management .

The purpose of the guide is to present some common-sense techniques thathave been shown to help project teams to plan and deliver successful projectout comes. These techn iques should be applied in a par ticipative man ner withall tea m m embers a nd k ey people involved in t he pr ocess.

Should you h ave an y feedback on t he t echn iques or sh ould you d iscover othertechniques tha t h elp you in plan ning an d ma na ging your project please let u sknow so we can sha re t hem with oth er project t eams.

Introduction


6/81

Page 6

Being involved in pr ojects is one wa y in which you can be par t of redesigningan d building an organ isation t ha t can meet t he challenges of th e 90s.Further, being part of a sucessful project is an interesting and enjoyableexperience.

We hope th at th is guide can as sist you in a chieving successful projects.


7/81

Page 7

M ost of us are used to working in an organisation where what we do isconsidered "business as usual". For example, Mary has a job calculatingsta tistics for th e nu mber of ma les and females employed in various indust ryclassificat ions. U sing mont hly sur vey form s, she checks each form, ent ers t he

details from the form into a computer-based spreadsheet and calculates thebasic statistics. Once the data is entered and summarised, Mary thencompa res t his mont hs figures a gainst previous m ont hs an d last years.Having documented any major variations, Mary prints the summary of indust ry employment da ta an d th en begins work on t he next m ont hs sur vey.

Different jobs, different dynamics

If we call this type of work p r o c e s s work, then we can identify a number of aspects of this t ype of work :

it r epeat s over a per iod of tim e

In Mar ys case, th e work cycle is a m ont h. In oth er pr ocess jobs, it canvary from less than a minute (factory assembly) to many months.However, for the majority of process jobs in most organisations, the cycleis less than a da y;

it is predictable

Because the work repeats, it is documented as a series of procedures orsteps. For most process jobs, the documentation is formal and is the basisfor on job training. Even if it is not written down, it is documented inpeoples "heads" an d is t au ght on th e job. Most importa nt ly, by following apredictable and documented set of procedures, we can ensure that asta ndar d process produces a stan dar d out put ;

Chapter 1

So what isspecial about

projects?


8/81

The Busy Persons Project Management Book

Page 8

it is easily measu red an d evalua ted

Most process jobs have clearly defined performance standards andmeasures. Typically, the person doing the job is informed on the expectedperformance and quality required and there is a formal measurement andreporting process that is used as the basis of performance evaluation.Becau se process work ha s short time-fra mes, it is measu red by out put s;

it operat es with in th e existing organ isation stat us-quo

Pr ocess jobs ar e th e backbone of th e existin g orga nisa tion. In other words ,doing process work does not chan ge the organ isat ion. Rat her process work opera tes with in th e orga nisa tions curr ent mission, objectives, pra cticesan d pr ocedures.

The vast majority of jobs - administrative, manufacturing, management andclerical - are clearly process jobs. Some estimates place the percentage of process jobs at over 90% of all jobs. These jobs are the jobs that we all knowand the very structure of our organisations reflect the pervasive nature of process work. Indeed, many organisations are structured around the various

process work categories i.e. Mary works in the Industry Statistics Section.Her friend Bill works in the Industry Statistics Publishing Section. Different jobs - differen t sections - sam e da ta .

Fig. 1 - Process work

Widget Pty LtdI make the Widget blatter.I've been a Senior Blatter

for 6 years.

Blatt Line

Blatter Monthly Production


9/81

So what is special about projects?

Page 9

From time to time, all of us will be involved in a very different type of work.This work is the exact opposite of process work. Mar y is asked t o work with asmall team of computer people to revise the system that processes her

statistics. Together with the computer people, Mary documents what isrequired to develop a new system that provides more information and canproduce the r esult s on a weekly inst ead of th e month ly cycle. As th e system isbeing developed, new ideas emerge and the team changes what they aredoing to include the new concepts. After a couple of months, the new systemis ready and Mar y tra ins a new person in t he system. Mary cha nges jobs andbecomes a business a na lyst.

If we call this type of work p r o j e c t work, t hen we can also identify a n um berof as pects of th is t ype of work :

it does not r epeat

Un derta king a project involves the t eam defining th e task s th at need to beundertaken. Although some tasks may repeat in other projects, mostprojects involve unique tasks. While most projects follow a similar "lifecycle", t he s pecific tas ks re flect t he pr ojects objectives an d out comes ;

it is dynam ic an d non-routine

Because the work is unique it is rarely documented as a set of standardprocedures. While process work repeats as a series of routine activities,project work is dynamic and can change during the project. Many smallprojects have been successfully undertaken with no formaldocum enta tion. In projects, you can ha ve a st an dar d process such as risk assessment, but the outputs of the process i.e. an assessment of the risksof th e project require un ique and non-sta nda rd ma na gement ;

it is not easily measu red an d evalua ted

Given t he dyna mic na tu re of project work, it is fairly har d to measu re h owthe project is proceeding and to set standards for performance. Also,whereas in process work, performance is measured by outputs that areproduced on a regular basis over short periods of time, projects take


10/81


Page 10

longer, often produce vary intangible outputs and success cannot bemeasured, in some cases, for many months. Many of the projectmanagement practices in this book are designed to provide a basis formeasu ring progress and success;

it changes th e existing organ isation st at us-quo

This is the key to the difference between process and project work.Projects change organisations and as a result require special attentionfrom all involved people. To put it simply, projects produce changes toexisting process jobs and create new process jobs. Projects are the keyvehicle via which organ isations cha nge wha t an d h ow th ey do th ings.

Fig. 2 - Pr oject work

Many people who have moved from process work to project work haveexperienced confusion and anxiety as they have moved from a work environment where everything was organised and standardised to a dynamicand flexible environment where the first thing to be done is to define whatth e work is required! This ha ndbook is a bout helping you t o make t he chan ge

from process to project work.

Different jobs, different skills

Most of the support services in organisations are oriented towards process

Widget Pty LtdWidget Pty Ltd

Blatt Line

NewBlattLine

After the Blatt ImprovementProject,

well have a more efficientcompany


11/81

So what is special about projects?

Page 11

jobs. Many of us have been on technical, supervision, leadership andmanagement training sessions that are oriented towards process work. Infact, the vast majority of training that we have received is either devoted tohow to do process work or how to m an age t hose people doing process work. Soit is n ot su rpr ising th at moving from p rocess work wh ere weve beenextensively trained (formally and on-the-job) to project work where there islitt le educat ion or procedures can be very fru str at ing.

All process work requires some technical knowledge. Even the simplest of jobs has some technical component. The filing of documents requires atechnical knowledge of the filing system, the structure of File Numbers andthe completion of file tracking records. The processing of an application for anew insurance policy requires technical knowledge of the correct completionof the a pplicat ion, t he informa tion r equired an d t he a pplicable business r ulesand procedures to validate and correct the application. Most organisations

provide t echn ical edu cat ion for people un dert ak ing pr ocess jobs.

As we move into supervisory and managerial jobs, we are required to learnnew skills and concepts. Standard supervisory tasks such as counsellingpeople, completing performance appraisals and providing direction to theteam require us to learn administrative and managerial knowledge. So mostpeople are involved in at least two types of work - technical andadministrative and during a normal day, we switch between these two typesof work quite easily. We have learn t t o balan ce technical a nd adm inistra tiveor m ana gerial tasks.

When you become involved in project work, you will need to learn some newskills. These skills are called project management skills. While they sharesome tasks in common with technical and managerial skills - negotiation,writt en a nd ora l commu nicat ion, t ask scheduling an d pr oblem-solving - man yof these skills ar e un ique to project ma na gement.

While industries such as construction and engineering have alwaysrecognised the need for formal project management skills, many servicesector organ isations are just beginning to underst an d th at th ere is a need forproject ma na gement. As you will see in th e rema inder of th is ha ndbook, th eskills of project management reflect the dynamic and complex nature of project developmen t.


12/81


Page 12

Fig. 3 - Differen t jobs, differen t skills

To summarise, projects are different to the majority of jobs that we havetr ained for an d tha t our ma na gers are used to mana ging - we need to acquireskills that will help us complete projects. We also need to become moreflexible and creative in our behaviour as projects require flexibility andcreativity.

The remainder of this book introduces these skills and provides some hints asto how to apply th em on your pr oject.

So, lets get sta rt ed.

Administrative/ Management

ProjectManagement

Technical/ Process


13/81

Page 13

Chapter 2 : Getting Started

You can think of a project as a journey. Like all journeys, if you want to

arrive safely it is sensible to do some planning before you start. The moredetailed the planning, the more likely that you will not end up where youdont wa nt to be. It is very import an t in projects t o ta ke some time t o do someup-front plann ing as it is likely th at youll be under pressur e to get un derway, into th e project a nd t o finish it a s soon a s possible.

The first step in plann ing your project is consider t hr ee related factors th atar e comm on to all pr ojects : who is involved in t he p roject ?

wha t is t he pr ojects scope or boun dar ies ? an d wha t a re t he objectives for t he pr oject ?

Well look a t t hese one a t a t ime an d th en see how they ar e related.

Who is involved in the project ?

Every pr oject w ill involve more th an one per son. In a typical sma ll project,you will probably be able to indentify the following people:

the project manager/project leader

This person is the leader of the team and is generally held accountable forthe outputs of the project. While this may sound a little "tough", the projectmanager would involve his or her team in all aspects of planning the projectand should expect assistance from the project sponsor in managing theproject;

th e project t eam m embers

These people are t he people directly involved in un dert ak ing t he pr ojectsta sks. They are th e key to the pr ojects success as th eir creativity a nd ha rdwork will be the m ajor input to th e project;


14/81


Page 14

th e pr oject sponsor

This person will normally be a manager or executive who is organisationallyresponsible for the projects resourcing, costs and success. The sponsor isan oth er k ey factor t o the pr ojects su ccess a s h e or s he will be expected tosupport th e project m an ager an d team in ar eas beyond t he tea ms cont rol an dauthority;

th e project clients

These people would be the people who are affected by the changes that theproject is implementing for the organisation. For some projects, the clientsmay be the team members but typically there are a number of people whowill have changes to their jobs and working relationships who will not be inth e team . It is essentia l tha t t hey are involved in the project;

support groups

These groups would be required to provide specialist support to the projectteam. Given that projects change organisations, typical support groups wouldbe Human Resources, Finance, Accomodation, Marketing and computer andother specialists;

oth er pr oject team s

In a time of organ isation cha nge, ther e will be ma ny other projects un derway.Some of these projects may have an impact on your project. Where there is aclear r elat ionsh ip between your project an d oth ers, the pr oject m an agers of the related projects should be kept aware of and, in some cases, directlyinvolved in your project.

These people are often called stakeholders or involved groups. They have a"stake" in the success of your project.

It will be normal for these stakeholders to have different views and concernsregar ding your project. H owever, if you involve th ese people in a positive wa yand early enough in your project, you should be able to achieve consensus. If


15/81


16/81


Page 16

begin an d end.

In process work, the boundaries of the job have been carefully defined overmany years and are generally detailed in the various job descriptions. For

example Mary [in her previous job] knows that it is her responsibility toenter the industry statistics and to produce the summaries. Her friend Billha s t he r esponsibility for t aking Ma rys sum ma ries an d publishing them .Ea ch job ha s clear ly defined bounda ries.

At the beginning of projects, the boundaries are generally not so clear ordocumented.

Sometimes, it helps t o thin k of project scope a s a circle or a series of flags inthe ground. Inside the circle is your project and the activities that you andyour team have to undertake. Outside the circle are your stakeholders andthe a ctivities tha t t hey have to undertake.

Fig. 5 - Project scope

Another way of thinking about scope is to specify what you are responsiblefor achieving and what you are not responsible for achieving. Some of youwill recognise this as part of the Kepner-Tregoe [1981] approach to problem-solving and decision making. While it may sound a bit strange, it is ofteneasier t o define wha t you a ren t doing in t he pr oject a nd, a s a r esult , clar ifywhat you mu st be doing. The example in Figure 6 should give you a n idea asto how this technique works.

Improved Blatt Project Team

This is where ourresponsibility is


17/81

Chapter2 : Getting started

Page 17

At early stages of your project, you may not be able to determine clearlywhat is "in" and what is "out". Again, it is very important to work with yourproject sponsor and stakeholders to resolve any queries or assumptionsregar ding scope.

Fig. 6 - Scope a nd objectives [Kepn er & Tregoe]

What are the objectives of the project?

If scope is where your responsibilities lie, then objectives are what you haveto achieve within those responsibilities. Most of us have had some training inthe importance of objectives and, in terms of your project, having clearobjectives is paramount.

If you dont know the scope and objectives of your project - you dont knowanything!

It is typical of projects , especially inn ovat ive ones, t ha t th e objectives m ay befair ly broad a nd high-level at th e beginn ing. For examp le, in Mar ys pr ojectth e initia l objective ma y be:

PROJECT : Industry Processing Statistics

IS NOT [Could be]IS

NOT RESOLVED

To redu ce processing tim e for rawdata from 10 days to 5 days

To produce Indu stry profiles withsub-industry categories

To provide job design


18/81


Page 18

To im prove the processing of ind ustry sta tistics

However, the more broad the objectives are, the more likely that the teamand the project stakeholders may interpret them differently. So it is

important to "fine-tune" the objectives as quickly as possible. Objectivesshould be as sp ecific an d mea sur able a s possible.

One tried and true technique for helping to develop measurable objectives isto "parse" the objective word by word to see if you can state the word in amore accur at e and precise man ner.

This techn ique should ensur e th at you h ave th ought th rough your objectivesbefore you start.

A common mistake when stating objectives is to state the "results" asobjectives. For example "To reduce costs" or "To improve service" are notobjectives but results or outcomes from doing something. Objectives shouldstate what you have to do to achieve the outcome of " improved service", for

exam ple. Another mista ke is t o stat e const ra ints as objectives. For example,"To implement a new team-based processing cycle by July 1" or "To deliverth e project u sing only th ree people" ar e sta tem ent s of const ra int s. Its notthat you can ignore any constraints such as timing, costs or resources thatapply to your project, you should list them as constraints.

T o imp rove the process ing of ind ust ry s ta t i s t ics

Are there any m easurescurrent ly ava i lable?

B y h o w m u c h ?Wh a t m easu re can show"im provem ent"?

Wh ich p rocess ing ac t iv i t ies?Wh o does t hem ?Wh ere are they done?Wh a t a r e t he cu r r en t problem s?

Can we be m ore speci f icas to wh ich s ta t i s t ics?W ho uses the s ta t i s t ics?

T o imp rove th e process ing of ind ust ry s ta t i s t ics

T o reduce processing t im e for rawd a t a f r om 1 0 d a y s t o 5 d a y s

To produce Indust ry prof i les wi thsub- ind ust ry ca tegor ies

T o develop an ad -hoc query fac i l ity for In du s t ry Pub l i sh ing


19/81

Chapter2 : Getting started

Page 19

How are these things related?

Scope, objectives and stakeholders are inter-related. If you change the scope

of your project, t hen you will cha nge your objectives a nd th e involved groupsor st ak eholders. If your projects scope expan ds, th en you will ha ve addit iona lobjectives and some previous stakeholders will become part of the team andth ere will be new sta keholders.

Fig. 7 - New scope then new objectives and new st akeh olders

Change is inevitable in most projects. What is important is that as long asyou have a clear and documented set of objectives and scope, then you candetermine the impact of the change and re-plan your project. The key pointhere is to "not panic". As long as you can manage the changes to yourprojects scope and objectives, youll be able to manage the project. Every timethe project changes you must stop to re-plan with your team and projectstakeholders.

As well discuss in later cha pters, t here a re other part s of th e project th at willcha nge with cha nges in scope an d objectives.

Improved Blatt Project TeamObjectives

ABC

D E

New Scope New Objectives

I'm now a stakeholder inthe expanded Blatt project

Oh! I used to be astakeholder.I'm now part of

the team

Now I've got a biggerproject


20/81


21/81

Page 21

Chapter 3 : What else to consider

As with a ll journ eys, th ere is more to consider when youre plan nin g tha n t heobjectives, scope and who else needs to be involved. You have to plan your

finances, the itinerary, stop-overs and insurances, for example.

In projects, there are similar factors that you and the team have to considerbefore you begin th e project in ear nest . In t his chapt er we will concent ra te ontwo factors - risk a nd pr oject st ra tegy - an d in t he n ext chapt er, well exam ineta sks, estima tes an d schedules.

Risk assessment

The concept of risk should be familiar to all of us. When you are planing anint erst at e busin ess t rip, you check out if th ere is t he likelihood of a refuellersstrike; whether fog or rain could delay the planes; whether there is enoughtime from when th e plane lands t o your ma king your appoint ment an d so on.In other words, you undertake a risk assessment. Risk assessment is theidentification of factors which can affect the probability of success for yourproject. The more likely the possibility of rain or a strike, the higher the risk of the journey and the lower the probability of you making the meeting ontime.

While the process of risk assessment in our everyday activities is generallydone "in our heads", in pr oject work, it is importa nt to examine th e risks in aopen an d docum ented ma nn er.

In pr ojects, t here a re t hr ee distinct ar eas or categories of risk:

product risk

This category of risk deals with the product or service that the team isdeveloping in the project. Some products are simple and therefore low risk while oth ers a re complex and of higher r isk. For example, Mary an d t he t eamwho are developing a new computer system and revised statistics processingcycle are working on a product (the new statistics system) that is notcomplex, is based on existing pr ocedur es an d does not r equire p rocessing a lotof dat a. Ther efore, th e tea m per ceives th e product to be rela tively low risk.


22/81


Page 22

The pr oduct r isk can be a ssessed by consider ing factors su ch a s :

how innovative is the product? ar e the requiremen ts well un derstood and st able? th e complexity of processing or pr ocedur es involved in th e pr oduct? an d are there high expectations for product performance or quality?

team risk

Different tea ms h ave different skills an d experience an d it is import an t th atyou honestly look at the team and its members to determine whether thereare some risks associated with the team and the team process. For example,Mary and the team have not worked together before, there are a couple of inexperienced computer people on the team and the project has very tightdeadlines. In t his case, the tea m a ssesses themselves as a h igh r isk team .

The team risks can be evaluated by considering factors which include:

how experienced ar e th e team members? ar e th ey full-time on t he pr oject? do th ey ha ve ma na gement support? an d do they ha ve a common working ar ea?

Dont worr y about declarin g your t eam to be a high r isk t eam . It doesntmean that you are incompetent or "out of control", it simply means that youar e undert aking a new and deman ding project.

tar get ar ea risk

As we discussed in the earlier chapters, projects change the way people work and the people and areas who are affected by the project (some of thesta keh olders) can be consider ed as t he "tar get" ar ea. In Ma rys project, th echa nges are pr imar ily directed to Mary an d th e people she works with in th eIndust ry Sta tistics Section a nd t o Bill an d his pu blishing group. They are allpositive about th e new system an d ar e prepared t o work with Marys tea m.


23/81


Page 23

Mary an d her team assess the ta rget risk cat egory as low.

Target a rea risks can be evalua ted by considering such factors a s:

ar e th e people impacted by the pr oject su pportive? ar e th ere a n umber of different sta keholders? ar e th e sta keh olders involved full-time or in a n a d-hoc fashion? an d is t he pr oject going t o significan tly a lter existing work flows?

Again, it is important to be honest about your evaluation of this risk category. Having a high risk target area does nor imply that they are arabble or that they are going to sabotage your project. It means that there is

a need to carefully support the people and to work with them to ensure thatth e pr oject succeeds.

Once you have evaluated and agreed on the risk factors and their score (Low,Medium or High), you can then come to an assessment of the overall risk of your project. In th e case of Mar ys pr oject, t he pr oduct wa s Low risk, th e tea mwas H igh r isk and th e ta rget ar ea wa s assessed as Low risk. Overall, Marysproject was considered as Medium risk because the team is an importantfactor in an y project bu t t he H igh t eam risk was offset by th e Low risk in th eoth er t wo categories.

A sample risk assessment questionnaire is included in Appendix C and youcan use it a s a ba sis for form alising th e risk a ssessmen t for your pr oject.

T he risk assessm ent process

As with all activities in planning and managing your project, the risk assessment process should be undertaken with your team members and, if possible, th e sta keholders for your pr oject. This is very importa nt as differen t

tea m m ember s will ha ve differen t views on t he r isks of your project.


24/81


Page 24

Fig. 8 - Differen t people see differen t r isks

What is really important is that the risk assessment is undertaken in ademocra tic fash ion. The best wa y for you an d your team to under ta ke a risk assessment is to copy the form in Appendix B for each member of the teaman d, if possible, any key sta keholders. Ea ch person an swers t he quest ions onth e risk assessment form a nd th en in a tea m session, you discuss th e answersan d see if you can reach a greement on t he r isk factors.

Given t ha t risk is genera lly subjective and persona l, you will find t ha t afterthe discussion, there may be still some risk factors upon which you cannotagree. In t his case, you vote and th e ma jority wins.

If you have a tied vote, then the worst case wins. For example, two teammembers see the project as Low risk and two see it as Medium, then theproject would be t reat ed as Medium risk.

It is also very import an t to note a ll high r isk factors a nd t o discuss with yourteam, stakeholders and project sponsor any actions that you and the teamcan implement before t he project st ar ts t o reduce and ma na ge the high risks.The capa bility of pro-active redu ction of risk before t he pr oject s ta rt s is a verypowerful aspect of forma l risk as sessmen t.

In Ma rys project, becau se th e compu ter people ar e inexperienced an d t he

I've worked on this typeof product before, it's

easy.

Well, that may be OKfor you but, I'm

not sure it is that easy.

Improved Blatt

Specification


25/81


Page 25

project has tight deadlines, some possible actions that she, in conjunctionwith h er pr oject sponsor, could implement to redu ce th e risk of th e project a reto negotiate a smaller scope and objectives for the project by producing asystem t ha t only processes certa in key sta tistics, to get some t ra ining for th ecomputer people and to see if there is a computer expert that the team canuse as a consultan t.

As well discover in t he n ext chapt er, t he r isk of a p roject ha s a n effect on t heestimates as well as on the probability of success. Further, the risk of aproject influences th e choice of th e pr oject st ra tegy.

Project strategy

When planning a journey, you face a choice as to how you organise youroverall approach to the trip. For an overseas trip you may decide to visit asmany countries as possible spend a couple of days in each place. Alternately,you may buy an open ticket which enables you to spend as little or as long asyou wish in a ny coun tr y. You m ay decide to quickly visit one a rea to check itout and then plan to return to that area for a longer stay later in your

journey. Another option is to take an organised tour that spens only threedays in each ar ea.

In projects, the overall approach is called the project strategy. Put simply, the

project strategy is about whether the project is done as one whole unit orbroken into sub-projects. There are four basic strategies which can be usedfor small a dministr at ive an d comput ing projects. These st ra tegies h ave beendeveloped in other industry areas such as construction and manufacturingwhich have extensive project management experience.

Lets assu me t ha t in Ma rys new pr oject, t he ba sic activities th at will berequired are Analyse Requirements (interview people, examine existingprocedures, to determine the requirements for new software), Design Solution(examine alternative mechanisms, procedures, forms design, etc to select an

appropriate processing design), Build Solution (develop new procedures,systems, training programmes, etc) and Implement Solution (install newprocedur es, tr ain people an d convert existing form s, etc).

monolithic strategy


26/81


Page 26

This strategy involves undertaking each development activity in sequencedeveloping the product or service as a whole. Each activity is completed andreviewed before the next activity starts. While each activity such as AnalyseRequirement s ma y be broken int o smaller t asks (see Work Breakdown in th enext chapter), all activities associated with Analyse Requirements are

complet ed before an y of the Design t as ks a re comm enced.

Fig 9. - Monolith ic Str at egy

This strategy is suitable for Low risk projects where the requirements aresta ble and t he pr oject environm ent is not likely to cha nge dur ing th e project.

sequential release strategy

In some projects, it may be more advisable for you to partition the projectinto smaller sub-projects and to implement the new product or service thatyou are developing as a series of small increments or releases. In this case,you have the choice of two strategies - sequential or concurrent release. Thesequen tia l releas e involves brea king th e projects requir emen ts int o segment sand developing one segment first using the monolithic strategy as shown inFigure 10. Once the first segment is implemented, the team moves to thenext segment or release.

AnalyseRequirements

DesignSolution

BuildSolution

Test & ShipSolution

AnalyseRequirements

DevelopRelease 1

DevelopRelease 2

AnalyseRequirements

DesignSolution

BuildSolution

Test & ShipSolution


27/81


Page 27

Fig.11 - Sequential Release Str ategy

In our example pr oject, Ma ry could develop n ew pr ocedur es only for a sub-setof th e processing (for capt ur ing th e basic data , for example), implemen t t hoseprocedures and then begin another project (release) on the more complexstatistics analysis. Alternately, she could develop all procedures for allstatistics processing but Release 1 only handles certain key industries withRelease 2 adding the other indust ries.

This strategy is suitable for most projects where you can negotiate thedelivery of partial products or services and there are some deadlineconstraints.

concurren t r elease str at egy

Concurrent release is an alternative to sequential release where the varioussub-projects and product components are developed concurrently asindependently as possible. As shown in Figure 12, you can schedule as manysub-projects or releases as you can staff the project. There are someadditional project management costs in this strategy as each release has itsown scope, objectives, risks a nd so on.

Fig. 12 - Concurr ent Release Str ategy

This strategy is suitable for all types of projects where you can break theproject u p int o releas es an d you h ave th e people to sta ff each relea se.

AnalyseRequirements

DesignSolution

BuildSolution

Test & ShipSolution

AnalyseRequirements

DevelopRelease 1

DevelopRelease 2


28/81


Page 28

fast -tr ack or evolutiona ry st ra tegy

This strategy is the most controversial of the project strategies as it involvesdeveloping a version of the product, procedures or services as quickly aspossible then after reviewing the first version while it is being used it isenhanced and improved through another fast-track project/release. It isinherent in the strategy that the quality of the early releases of the productwill be lower tha n in th e oth er str at egies and t ha t r efining and improving th eproducts qu ality wh ile it is being u sed is m ore expen sive.

However, for high risk projects such as innovative products or products withdynamic requirements, this strategy is quite successful. The proviso here isthat all stakeholders and the project sponsor must be comfortable with the

use of th is stra tegy and its qua lity problems in t he sh ort term . The oth erdan ger with u sing the fast-tra ck st ra tegy is th at it becomes an excuse for lack of planning and rushed delivery. You still plan and control a fast-trackedproject - you only cut corner s th at ma ke sense.

Fig 13 - Fast -track or Evolutionar y Stra tegy

You should treat the choice of the project strategy as one of the most

importa nt decisions t ak en du rin g project pla nn ing. As well explore inChapter 7, the changing of project strategy, from monolithic to sequentialreleas e, for exa mple, is a powerful techn ique for d ealing with project cha nges.

AnalyseRequirements

DesignSolution

BuildSolution

Test & ShipSolution

Fast-trackVersion 1

ReviewVersion 1

DevelopRelease 2

ReviewVersion 2


29/81

Page 29

Chapter 4 : Different projects, different paths

Having determined your scope, objectives, stakeholders, risk and potentialstrategies, you and the team can begin to determine the specific tasks andestim at es for your project.

Again, when planning a journey, we are faced with similar activities. For ourbusiness trip, we have to decide what tasks, time and sequencing areinvolved in getting packed, organising the kids, getting care for the pets,packing an d so on.

In our day-to-day pr ojects, we t end t o do th ese activities inform ally an d oftenby rote. When planning projects, the processes of task identification andestimat ion ar e too import an t to be done quickly an d inform ally. As with th eother activities required for developing our plans, the task listing, estimationand scheduling should be done in a open team session. If there are taskswhich require stakeholder involvement, they should also be involved in thesekey processes.

Task identification or work breakdown

It is surprising that task listing is probably the easiest part of projectplanning yet one of the most important. One of the most common reasonswhy projects ta ke longer t ha n expected is t he simple fact t ha t th e tea m forgotan important task while planning their project. When you're working on a 6week project and discover that you have to add another 6 week task - you're100% behind schedu le imm ediat ely.

Task identification involves an approach that is formally known as projectdevelopment life-cycle or work brea kdown st ru ctu re or, for technical pr ojects,a m eth odology. However, despit e th ese impr essive term s, it simp ly involves a

series of loops involving th e brainst orm ing of tasks an d t hen breaking u p t hetasks into smaller sub-sets as shown in Figure 14. You should allow thebrainstorming process to be as creative and as free-flowing as possible. It isvery important to not confuse the task identification with the process of scheduling the tasks. Just let the team identify the tasks in any order andth en worr y about th e sequence of un derta king the ta sks in a separ at e session- see scheduling later in Cha pter 5.


30/81


Page 30

As we get m ore experien ce in pr oject work , you will begin to notice tha t someprojects tend to involve similar tasks. As a result, you can begin to developbasic templates of tasks or work breakdown structures for specific projecttypes. A basic project development life-cycle is included in Appendix C. Thiscan provide a bas ic fram ework for developing your own project ta sk list .

While you and your team are identifying the tasks, the following tips shouldhelp you in th e process:

5/10day rule

It is a good idea to keep breaking up the tasks into smaller tasks until youar rive at ta sks th at would ta ke between 5 to 10 days to complete. This ma kesit ea sier t o keep tr ack of how you're going dur ing th e project;

ha s a nyone been h ere before?

See if you can find anyone who has experience in the type of project you'replanning or who has been involved in doing similar tasks in other projects.This is common sense but it is surprising that the not invented heresyndr ome exists in pr ojects a s well as in oth er a ctivities;

what is the output from th e task?

For each task you list check out that everyone in the planning sessionun dersta nds th e out put s th at will be produced when t he t ask is complete. Forexample, a visit t o oth er u ser sites of th e tr aining vendors will result in a SiteVisit Report .


31/81


Page 31

Fig. 13 - A work breakdown str uctur e

Probably the most important tip is that a team will always produce a morecomprehensive work breakdown than an individual. By using your teammembers and stakeholders to help you identify tasks, you will get a moreaccurate list and a better understanding by all team members of what isrequired from t hem in th e project.

Task estimation

Having got your task list, the next step in planning your project is toestim at e th e ta sks. Before we look at a couple of techn iques th at can h elp youderive more accur at e estimat es for t he t asks, we mu st get some groun d-ru lesclear:

look a t differen t scena rios

In our day-to-day activities we have been taught to estimate using a singleestimate. For example, most of us will say to friends whom we are meetingfor dinner I'll meet you at the restaurant at 8.00 pm. In estimatingprojects, it is better to consider three scenarios : Best case which assumeseveryth ing is per fect; Likely which a llows for s ome t hin gs not going well an d;Worst case wher e everything goes badly. In our resta ur an t example, the Bestcase is when th e babysitt er is on t ime, the kids do not wa nt you t o help th emwith their homework and the car has enough petrol. As a result, you get to

Evaluate Training

Examine TrainingDocumentation

Conduct PilotProgramme

Evaluate Vendors

Review Pilot

Contact Vendor Clients

Contact Accountants

Visit OtherVendor Sites

Confirm ServiceAgreementsDetermine Available

Training

Determine PilotProgramme Requirements


32/81


Page 32

the restaurant at 7.50 pm. The Worst case is that the babysitter is 20minut es late, the kids want you t o watch th e end of Neighbour s an d th e car isout of petrol, etc. You arrive at the restaurant at 9.15 pm and your friendshave left. As you can probably see, the same things can happen in projectsan d your project sponsor, team an d sta keholders sh ould all be ma de awa re of the Best, Likely and Worst case situations and estimates. This approach iscalled Sen sitivity Analysis;

risk has a n impact on estimates

Our risk a ssessment, which you m ust complete before you est imat e th e ta sks,will have a significant impact on the size and accuracy of your estimates.Simply, the higher the risk the bigger the estimate and the higher theprobability that your estimates will be wrong. Let's assume that Mary isplanning a visit to various companies that use an education vendor that shewishes to review. She has three sites to visit. In a low risk project scenario,the three sites are within walking distance of her company, the trainingpeople in the sites are prepared to co-operate and Mary is allocated full-timeto the project. In a high risk project scenario, the three sites are in differentcities, the tr aining people in th e sites ar e busy an d a re giving Mary's visit alow profile and she are part-time on the project. Clearly, in the high risk scena rio, she will ta ke mu ch longer to achieve the r eview;

a t eam estimate is always better t han an individual estimate

Each one of us has skills that we have mastered and as a result we have agood understanding of how long it will take us to undertake tasks involvingth ose skills. In pr oject work , you will often be requ ired t o estima te h ow long ata sk will ta ke an d th at ta sk is one where you do not ha ve experience or sk ills.In this case, an open discussion with the team about the task estimate (aswe'll discuss later) will enable you to get a better grip on what the task involves and how long it sh ould ta ke. In ma ny cases, it is not t he estima te of the task that is wrong but the understanding of what the task involves.

Further, because we are all so different in skills and capability, a groupdiscussion of estimates will provide different views, assumptions and a moredetailed underst an ding of the complexity and r isks of the ta sk r esulting in amore accur at e estima te.


33/81


Page 33

Fig. 14 - Let's ta lk about it

separate effort from duration

This guideline ma y appea r a lit tle st ra nge to some of us. H owever, in projectswe are really working in two times. The first is the actual time (effort)required t o complete th e ta sks a nd t he second is t he du ra tion (elapsed effort )required to allocate the effort. For example, Mary requires 6 hours to reviewthe specifications of her project but because of other tasks she can onlyallocate 2 hours a day so the elapsed time is 3 days for the 6 hour task. Youshould estimate in effort first then as discussed in the next chapter, adjustth e effort estimat es to durat ion du ring th e scheduling of the ta sks.

Delphi estimation

A very good approach for estimation of both effort and duration is based onth e Delphi technique developed by Herm an Kahn of the Hu dson In stitu te for

use in predicting long-term social and economic trends. It is a team-basedtechn ique a nd is easily ap plied for all t ypes of projects .

It in volves 9 simple st eps:

Step 1 - provide team members and stakeholders with the relevant

I think the design is easyand should take 5 days

max.

Yes and don't forget thatwe have to talk with

Human Resources .. that'lltake 2 days

Improved BlattDesign

What about the Splatcomponent? It isn't easy

at all.. 6 days for sure


34/81


Page 34

information regarding the project, ie. the scope, objectives andsta keholders as described in Chapt er 2;

Step 2 - conduct a formal risk assessment and select the projectdevelopment strategy as described in Chapter 3 to ensure that all teammembers h ave discussed th eir assu mptions and views;

Step 3 - brainst orm t he ta sk lists as described ear lier in th is cha pter;

Step 4 - each person individually estimates each task using SensitivityAnalysis to provide a Best case, Likely and Worst case estimate for eachta sk. The Best case a ssumes everything goes as well as it can , the Likelyassu mes th at some problems will occur a nd th e Worst a ssumes t ha t m an yth ings will go wrong and our a ssumpt ions a re incorr ect;

Step 5 - all estimates are written on to a whyte-board and grouped in thethree ranges;

Step 6 - each person discusses the various assumptions and issues theyconsidered when developing their estimates;

Step 7 - where required, the various estimates are adjusted based on theteam discussion;

Step 8 - each range is averaged with out-riders (those estimates that arenot adjusted through the team discussion and are outside the rangesevidenced in th e estima tes) are discar ded;

Step 9 - the resultant ranges are used as the basis for scheduling asdiscussed in th e next cha pter.

The Delphi process result s in a highly-discussed a nd ra nged set of estimatesas sh own in F igur e 15.


35/81


Page 35

Fig. 15 - Wide-band Delphi estimates

Now that you h ave thr ee estimates for ea ch t ask, th ere ar e two easy ways fordetermining which of the three estimates you and your team will use fordeveloping the project schedule. The first is to select the range reflecting the

risk of your pr oject. Th at is, for a Low risk project you will use t he Best cas eestimat es; Medium r isk uses t he Likely and; High risk you will use t he Worstcase. A better variation is for you and the team to complete a quick andinforma l risk a ssessment of each ta sk a nd t o use the ra nges as above for eachtask. For example, in Mary's project, she and the team see the analysing of the current system as Low risk and use the Best case estimate for that task.However, th e program ming is seen as H igh r isk and th e team uses th e Worstcase estimat e for th at t ask.

Don't worry if you spend a fair bit of time in developing your task lists andestimates during the project planning process. The task listing andestimation process is vital in developing the costs for the project and forproviding the basic data for developing the final project planning outcome -th e project schedule. It is obvious t ha t t he m ore r igorous t he estima tion an dtask listing the more realistic would be the schedule and other projectinformation.

Given that many projects are about significant changes to the way we dothings, it is probable that our estimates will be wrong because of thenewness' of th e task s we have to undert ake. What is importa nt here is not tohide the fact tha t you ha ve ma de estimation err ors but r at her t o immediatelysee your project sponsor and discuss what needs to be done to re-plan theproject. We'll discuss t his in m ore detail in Cha pter 7.

3 8 10 6 7 9 18 16 18 15 17 9 24 22 25 40 26 27

Best Likely Worst

Average : (excl. Outriders)

8 17 25


36/81


Page 36

A very brief note on project costing

The team estimates can be used as the basis for developing the project costs.

In most small projects, the biggest cost component will be people and theirtime. However, in some projects, there will also be some costs required topurchase new equipment such as computers, furniture, printing and trainingequipment, for example.

Your organisation's Finance people in your area can give you assistance indeveloping the various costs involved in your project


37/81

Page 37

Chapter 5 : Finalising the plans

The final process in developing your project plan is to develop the projectschedule - the sequencing of the tasks and the allocation of team membersan d stak eholders to th ose tasks.

In planning our journey we often tend to plan the schedule for our journeybefore we've sorted out the estimates, costs, availability of flights and risks.As a result, once we've contacted the airlines, we have to re-plan our entire

jour ney because of costs an d schedu les.

In planning projects, the scheduling of tasks is the last process of planning.However, as we'll cover later in this Chapter, once we have developed ourschedule, we may need to re-schedule certain tasks or people to shorten theschedule or t o more efficient ly allocat e team mem bers a cross th e ta sks.

In developing the project schedule, there are three basic steps. The first is todevelop th e network or relat ionsh ips between t he t asks; th e second st ep is toallocate the people and adjust the estimates for duration (remember that wemade our estimat es in effort in th e previous cha pter) an d t he fina l process isto ad just th e schedule for efficient allocation of resour ces.

However, before we get int o developing t he s chedu le, we need t o look a t somebasic concepts beh ind t he s chedu ling process.

Task dependencies and relationships

The key to scheduling is to determine which tasks require something fromoth er t asks before t hey can sta rt . That is, you m ust ident ify the dependenciesbewteen your tasks. For example, in planning our journey, until you'vebooked your flights you cannot confirm your hotel bookings.

There are two major types of dependency. The first is one task requires theoutput from another - a delivery or output dependency. In Mary's project, sheneeds to evaluate the various education vendors and produce a Vendor


38/81


Page 38

Report before she and the team can commence the pilot educationprogramme. Alternatively, a task may require a person to finish a task sothat they start another task - a resource dependency. Once, Mary hasfinished producing the Vendor Report, she can begin designing the trainingprogramme.

There are different types of relationships between tasks as well. The mostcommon relationship is called a finish-to-start relationship. In thisrelationship between tasks, one task must finish before the dependent task can start. This relationship is often associated with output dependencies.However, sometimes it is possible to overlap tasks. For example, once Maryha s sta rt ed an alysing her cur rent procedures, she can a lso begin to docum entthe problems of the current statistics processing. This relationship is called astart-to-start. With start-to-task relationships you must identify how longafter t he first task has st art ed the second t ask can sta rt . That is, if a task canstart two days after another task, this will be indicated on the relationshipdiagram.

Figure 16 shows th ese dependencies and relationships.

You can also have finish-to-finish and start-to-finish relationships but thesear e less comm on in s ma ll projects.


39/81


Page 39

Fig. 16 - Task depen dencies an d relat ionsh ips

Developing the task network

The first step in developing the project schedule is to develop a task network diagram. These diagrams are also known as a PERT/CPM (Program

Evaluation and Review Technique/Critical Path Method) diagrams. In thesediagrams the tasks are shown in boxes and relationships (which aregenerally assumed to be output or resource) are shown as lines between thetasks. In Figure 17, it is implied that Select Vendor is dependent uponEvaluate Vendor being completed. When there is a number or lag shown onthe relationship lines a start-to-start dependency is implied. In Figure 17,Document Problems can start 2 days after Analyse Current Processing has

VisitReport

EvaluateVendors

SelectVendor

Resource Dependency

Output Dependency

EvaluateVendors

SelectVendor

5 3

EvaluateVendors

SelectVendor

2

5 6

AnalyseCurrent

Processing

DocumentProblems

Dependencies

Finish-to-start

Start-to-start

2 day lag

DocumentProblems

AnalyseCurrent

Processing


40/81


Page 40

commenced.

To develop a network diagram is relatively simple. All you and the team haveto consider is (1) which tasks are dependent on other tasks either because of

output or resources and (2) can other tasks which can be done while othertasks are being done? While the concepts behind developing a network foryour project are easy, the process can be quite complex as there are manyoptions available for the sequencing of the tasks. For example, Mary's teammay decide to wait until they have finished their analysis of requirementsbefore they begin to examine alternative implementation options. However, itis also possible to examine some options while analysing requirements. Theprocess must involve an open team discussion to explore all schedulingalternatives and the final choice of network will depend on which people areavailable and are there some clear output-related dependencies. Figure 17shows a partial network for Mary's project.

Fig. 17 - Basic network diagram

Factor in adjusted estimates and people

Once you h ave settled on your basic network, you a nd t he t eam can th en a ddin the estimates and allocate people to each task. Taking each task in turn,you a nd t he tea m m ust first a djust th e effort estimat es tha t you developed inyour estimat ion process (remember Cha pter 4?) to elapsed t ime or dur at ion.

The key here is to allow for non-project activities and/or work on otherprojects as you adjust the effort to elapsed. It 's a bit strange but while

StartTraining

Programme

DeterminePilot Prog

Requirements

EndTraining

Programme

Milestone : a task with zero duration

EvaluateTraining

Documentation

ConductPilot

Programme

ReviewPilot

Determine

AvailableTraining

EvaluateVendors


41/81


Page 41

projects involve effort, they are measured in duration or elapsed days. Forexample, Mary estima tes t ha t it will tak e her 24 hours of un -interu pted effortto Evalua te Tr ain ing Docum ent at ion ( 3 days @ 8 hour s per da y). However,she has to spend 2 hours a day on keeping the current Industry Statisticsprocessing underway and 1 hour per day on administration and processman agement. So she only has 5 hours per day for t he pr oject a nd t he elapseddur at ion for E valua te Tra ining Docum ent at ion is 5 days (4 days @ 5 hoursper da y an d 1 da y @ 4 hour s).

Often, you may also be able to schedule to enable more than one person towork on a task. This adds another dimension to your adjusting the effort toduration. Let's assume that Mary can use Fred to help her to evaluate thetraining documentation. They have to consider whether the task can beequally divided between them, are there communication overheads as theyneed to talk with each other and review each other's work and so on? As aresult, they decide that the task originally estimated as 5 elapsed days (24hours effort) with Mary working by herself will take 3 elapsed days with Fredhelping. However, the total effort now involves 16 hours of Mary's work and16 hours of Fred's time. In other words, the duration has been reduced butthe cost/effort of the task has been increased from 24 hours to 36 hours. Suchis the fun of scheduling. Figure 18 shows the network and adjusted elapsedestimates.

Fig. 18 - Network with a djusted estimat es

The adjusted n etwork can be then used t o derive or calculat e th e critical pa thfor the project. The critical path is a mathematical calculation of the longestpath (in terms of duration) of tasks and relationships through the network.Finding the critical path is essential to managing your project. If the task

StartTraining

Programme

DeterminePilot ProgRequirements

EndTraining

Programme

EvaluateTrainingDocumentation

ConductPilotProgramme

ReviewPilot

DetermineAvailableTraining

EvaluateVendors

10 3 10 5

5 10

Critical Path


42/81


Page 42

Determine Available Training takes 6 days instead of the 5 days estimatedth en t he t asks - Evaluate Vendors, Condu ct P ilot P rogra me a nd Review Pilot- all slip one day and the whole group of tasks is delivered one day late.However, if the Evaluate Training Documention slips one day it will notaffect the related tasks. All tasks that are not on the critical path have floator slack. Float is the number of days a non-critical path task can slip before itaffects the critical path. In the case of Evaluate Training Documentation, itha s a float of 7 days.

Once the network has been loaded with the adjusted estimates, you and theteam can derive a Gantt or task timeline diagram. This diagram displays thenetwork as a series of bars representing the tasks and their elapsed timeagainst a calendar. The Gantt chart is a direct sub-set of the network diagram and is developed by extracting the tasks from the network andaligning them a ccording to a sta rt da te an d the calenda r.

The Gant t char t a lso shows tasks with float with a sha dow or m odified bar a sthe float time. You and the team will find the Gantt chart as the most usefuldiagram for monitoring and controlling your project as it clearly shows thetasks against the calendar. What the Gantt chart does not show is therelationships or dependencies between th e ta sks - only th e network diagra mshows those. Figure 19 shows the Gantt chart assuming Mary starts onFebruary 25.

Fig. 19 - The first cut GANTT

Determine Pilot ProgReqd

Feb25

Mar4

Mar11

Mar18

Mar25

Apr1

Apr8

Apr15

Apr22

Determine Avail.Training

Evaluate VendorsConduct PilotProgramme

Review PilotEvaluate TrainingDoco

Critical Path

Non- Critical

Path


43/81


Page 43

Season to taste

If your project has a deadline, the development of your network and Gantt

chart will show whether you can make it. If your project cannot make itsdeadline, then you and the team must re-visit your network diagram and seeif you can overlap tasks, change the sequencing of tasks or re-allocate teammembers t o ta sks to short en th e schedule.

Let's assume that Mary and her team have to complete the training sub-setof her project by April 15. The initial schedule developed by her team showsth e estimat ed finish dat e of April 22. In a team discussion, Mar y decides t ha tthe team can overlap the tasks Determine Pilot Programme requirementsan d Determ ine Available Training by 3 days (she cha nges th e finish-to-sta rt

relationship between the tasks to a start-to-start with a lag of 7 days). Theteam also decides that Fred can assist Mary in the task Evaluate Vendors sothat the duration is reduced from 10 to 5 days as well as helping her inEvalua te Tra ining Docum enta tion. As a result of the re-scheduling, the t eamcan now meet th e deadline a s shown in Figures 20 an d 21.

Fig. 20 - Adjust ing Elap sed

StartTraining

Programme

DeterminePilot Prog

Requirements

EndTrainingProgramme

EvaluateTraining

Documentation

ConductPilot

Programme

ReviewPilot

DetermineAvailableTraining

EvaluateVendors

10 3 10 5

5 5

Mary and Bill both full-time @ 5 hours/day on task work with 1/day

for coordination

Elapsed time Total effort 80 hours

7


44/81


Page 44

Fig. 21 - Re-scheduled Gant t char t or we can m ake it!

The most comm on wa y of re-scheduling a project is by t he t echn iques u sed byMary's team. By over-lapping tasks and by careful allocation of moreresources (remember you may shorten the duration but will increase theeffort /cost), you can norm ally optimise t he schedule. H owever, you should becareful as there are some tasks that will not be shortened by adding extrapeople and, in some cases, adding too many people can actually increase thedur at ion a nd cost becau se of administr at ion an d commu nicat ion overheads.

A note on scheduling software

There are a number of PC-based scheduling tools that can assist the team indeveloping the project schedule. These software packages can automate theprocesses such as network diagrams and Gantt charts covered in thisChapter. Further, these tools can produce other useful planning and projecttr acking diagra ms su ch a s Gan tt cha rt s for ea ch individual, resour ce loading(who has too much work), task lists including who has been allocated toundertake them and turn-around forms which allow you to enter in theactua l progress.

Before we cont inu e to look a t a dditional pr ocesses a nd concepts for m an agingour small projects, let's summarise. At the end of your project planningsession, you and your team should have documented the followinginformation :


Feb25

Mar4

Mar11

Mar18

Mar25

Apr1

Apr8

Apr15

Apr22


EvaluateVendors Conduct Pilot

Programme

Review PilotEvaluate TrainingDoco


45/81


Page 45

pr oject scope; pr oject objectives; sta keholders a nd r elated projects; project risks a nd r isk reduction str at egies; th e appr opriat e project development str at egies; th e ta sks r equired for t he pr oject; estimat es (effort an d du ra tion); project schedule; any constr aints and assumptions.

This set of information is often termed the Business Case as it containsinformation relating to the project management aspects of the project asdistinct from the technical details (remember Chapter 1?).

The Business Case would have been developed in a series of team-basedsessions as discussed in the earlier chapters. As also discussed, whenpossible, the va rious st ak eholders of your project would h ave been involved inthese planning sessions. Any problems regarding the details of your projectsuch as the scope, objectives and risks should be raised with your project

sponsor for assistance and resolution.

Remember, although t here a ppears to be a lot of inform at ion required for th eproject you're about to undertake, the main reason that you gather thisinformation is to ensure that you, your team, project sponsor andstakeholders are in agreement as to what the project is about and what islikely to happen during the project.

T he Bu siness Case is th e m ap for your p roject journ ey.


46/81


47/81

Page 47

Chapter 6 : Keeping it together

So you a nd t eam ar e fina lly on your wa y an d your project ha s comm enced. Aswe have discussed throughout this book, there are many things that you andth e team ha ve to keep an eye on.

Just as in our journeys where planes can be delayed, bad weather caninterr upt some of our plann ed stop-overs an d th e children get sick, th ere ar emany factors that can prevent the project from going to plan. Clearly, themore rigorous and participative your planning session, the more likely thatyou a nd t eam would have included adjustm ents a nd a llowances for t he r isksand so on. However, to ensure that your project has not started to get off-

the-track then, as in most activities associated with project management,you must formalise the monitoring of progress and the reporting of progressto your st ak eholders an d project sponsor.

In this chapter, we will cover how to track your project, what formal reportsyou should be producing and what should you do when things change in yourproject.

Project Tracking

Project tracking has one major objective - to determine whether your projectis in cont rol, i.e. meet ing a greed dea dlines, objectives, estim at es a nd so on,or out of control. As soon as your project has slipped out of control, youshould immediately undertake project re-planning which can include re-negotia tion of th e Busin ess Cas e an d t echn ical specificat ions for your project.This tracking process is most simply achieved by a combination of formaltr acking procedures an d regular t eam meetings.

The initial focus of project tracking is to review the status of the Business

Case to determ ine any a ctu al or poten tial variat ions. Should any var iation of the Business Case, in particular, the scope, objectives and risk, occur youshould use formalised change control as described later in this chapter.

Apart from checking whether there are significant changes to the BusinessCase, a secondary focus for project tracking is for you and the team tocompare the number of tasks completed with the number of tasks you


48/81


Page 48

planned to complete and the actual effort and duration versus the estimatedeffort an d dur at ion.

In other words, project t ra cking is dependent on t ask tr acking. Task t ra cking

is undertaken by each team member working on the project while projecttracking is achieved by you and the team summarising the actual task effortcompleted by team members and stakeholders using the project plan and asthe benchmark. Most PC-based scheduling tools provide the capability of enter ing actual effort against th e estimat ed effort .

Provided that you and the team followed the 5/10 day rule detailed inChapter 4, for purposes of both project and task, you should treat tasks aseither complete or n ot complete; alm ost complet e ta sks count ed a s complet ewill give you an inaccurate picture. This approach simplifies project trackingand avoids the 90% complete syndrome wherein a task remains almostcomplete for a period of time. The formal term for this is called the Zero-Hundred Percent technique.

It should be noted that there are other methods of tracking completion of ta sks. One technique commonly used is the Linear Pr ogress appr oach wher ethe percentage complete is calculated from the actual duration versus theestimated duration. If a task was estimated at 20 days duration and 10actua l days ha ve been spent th en t he t ask is 50% complete. A variat ion of th eLinear Progress technique is a subjective evaluation of the worth of theactual effort. For example, although 10 days of 20 days have been spent, theperson undertaking the task subjectively assesses that it is 70% complete.However, you will find t ha t t his t echn ique can be very distorted by subjective

judgements and, more importantly, by last minute difficulties in completing atask (many of us like to leave the hardest bits until last). So you should useth e Zero-Hu ndr ed Per cent technique for your tr acking.

While you and the team will find that project tracking is typicallyundertaken on a weekly or bi-weekly time-frame, it should be emphasised

that as soon as a team member or stakeholder realises that they will notmeet their task deadline, i.e. they are out of control, they should notify youso that the requisite corrective action can be taken. Clearly, this is vital forall tasks on the critical path of the project. For non-critical path tasks, thisaction would only be requir ed if th e cha nge exceeds th e ava ilable float for th etask.


49/81


Page 49

Fig. 22 - Project t ra cking m eeting

An useful diagram for task tracking is a Gantt chart for each person on theproject (see Figure 23). Most P.C.-based scheduling tools will provide thischart. These charts provide each team member with a clear picture of theirindividual work effort while the overall project Gantt chart provides eachteam member with a common vision of how the effort of all team memberscombines in t he pr oject.

Fig. 23 - Individual Gant t : an essential tr acking model

I'm going OK on Task Abut Task B is behindby 3 days

Yes so can I as I'm ahead onmy Tasks C and D

Improved BlattProject

Task ATask B

Task C

Task DThat's fine.

I can help you on Task Bas I'm off thecritical path


Feb25

Mar4

Mar11

Mar18

Mar25

Apr1

Apr8

Apr15

Apr22


EvaluateVendors

Conduct PilotProgramme

Review Pilot

Evaluate TrainingDoco

Mary

Bill

Review Pilot


50/81


Page 50

The other focus of project tracking is to collect data to assist you in costingan d in th e creat ion of an est imat ing history. This involves project you an d t heteam members recording actual and elapsed time spent on the variouspha ses/task s of th e project.

The actual work effort and actual elapsed duration spent on each projectphase/task should be recorded daily by each project team member on aproject/task tracking document.

This information is required to assist in collecting an estimating history forfuture projects and, in some cases, for the accumulation of costs forexamining the cost-benefits of the project. You should be clear that trackingeffort an d dur at ion is n ot a time-keeping or personal evaluat ion docum ent. Itwould be quite legitimate for no work to be done on a project task during aday.

It is not necessary to balance the number of hours each day or to ensurethat the entire 8 hours of the day are accounted for. Project tracking tracksan d monitors p rojects, n ot p eople.

Using this approach you and the team can then assess the accuracy of theestimated work effort versus actual work effort and estimated elapsedduration versus actual elapsed duration and, where necessary, adjust theschedule as discussed in Cha pter 5 an d re-plan th e project.

You a nd t eam members m ay also wish t o track work on other activities suchas support of existing products, a ctivities su ch as meetings, adm inistra tion of your people, tr avel costs an d so on.

Project reporting

The format and timing for your project reporting will depend on the length of the project i.e the shorter the project, the shorter the reporting cycle. InMary's project, the estimated duration of the project was 4 months, so shean d th e project sponsor agreed th at a fort nightly project r eport was r equired.

The essential information that should be forwarded to your project sponsor


51/81


Page 51

an d key sta keholder ar eas is:

th e sta tu s of th e project, i.e. is it st ill proceeding to plans or n ot; if not, what is the r evised situat ion a nd causes for t he variat ion; wha t a ctions h ave been t aken by the tea m t o solve an y problems; wha t a lterna tive scenar ios are available; what actions can be tak en by the pr oject sponsor a nd st akeh olders; an d revised or upda ted Business Case.

In addit ion, pr oject report ing could a lso involve an aggregat ion of actua l coststo dat e for t he pr oject.

Control of project change and variation

Despite the best of our intentions and plans, it is almost inevitable that theneed for change will occur some time before you finish your project. What youneed is a pre-agreed process to evaluate and process the impact of changes tothe Business Case and the re-planning of your project should the impact besignificant.

In t his cont ext, you will find th at cha nges can be intern al or externa l:

internal changes are those that arise during project development due tomis-understanding of requirements, estimation errors, project teammember chan ges, invalid assu mpt ions a nd t echn ical issues t ha t could notbe foreseen dur ing th e initia l plann ing of th e project;

external changes are those that arise through changes in stakeholder or

client requirements, new policy decisions, new/changed ideas,requirements of other projects and so on, which were not part of theoriginal product specification.

Although it is likely that an internal change will almost always be acceptedby the team as being essential, for control purposes, both internal andexterna l chan ges must be treat ed in th e same mann er.


52/81


Page 52

Control of changes involves three steps - request for change, evaluation anddecision:

request for change

All requests for change must be documented no matter what the source,other wise you will lose t ra ck of your project. Th e requ iremen t is for a brief note addressed to the you and the team which must include theoriginator's name, date of request, description of the problem addressed,description of th e cha nge a nd ju stificat ion for it .

evaluation

You and the team must evaluate the change. This would be normallyachieved through the convening of a team planning session which wouldas sess t he following:

is th e cha nge rea lly just ified?

if justified, is it essential that it be made at this time or could it oranother feature be deferred until after the Post-ImplementationReview pha se at th e end of th e project?

does the change alter the scope, objectives and stakeholders of theproject?

what tasks, whether completed, in progress or to be commenced, wouldbe a ffected?

estimat e of work effort an d dura tion required to implement chan ge?

will it requ ire r e-schedu ling of the pr oject an d/or ext end t he complet iondat e of th e project a nd/or a cha nge of project developmen t st ra tegy?


53/81


Page 53

will it require additional resources to carry out?

does t he cha nge impa ct across sub-projects or componen ts?

does it a lter th e complexity an d risk of th e project? an d

what risks are involved whether the change is implemented or notimplemented?

decision

Assuming that you have no doubt that change should be made at thistime, an d provided it will not require a dditiona l resour ces, alter th e risk,alter th e Business Case a nd/or extend th e completion dat e of th e project,it can be a ccepted.

If there is some doubt, or if the change is very extensive, you should call ameeting between stakeholders including the requester of the change. Thismeeting should discuss all aspects involved and come up with arecomm enda tion for t he sponsor t o proceed or oth erwise.

If you decide to adopt the change, you and the project team must take thenecessary steps to put it in train. This will mean that you should conduct anew project plann ing session session. It mu st be r emembered th at wheneverthe project moves out of control as a result of either external or internalchange, you must conduct another project planning session.

For example, in Mary's project, one of her clients requests changes in the wayin wh ich t he st at istics are being coded. As Mar y's project's dea dline can not beextended, Mary decides to change the development strategy in her project toaccomodate the changes. She chooses to move from the original Sequentialrelease to a Concurren t Release stra tegy by keeping her initial tea m workingon the original specifications and to add a new team member to alter thecodes as a new r elease.

In most projects, by renegotiating the project's scope, objectives, resources,


54/81


Page 54

deadline a nd st ra tegy, you can ma na ge the chan ges to your project. The keyis to make t hese negotiat ions open an d par ticipative.

So you've planned, tracked, reported and managed the changes to your

project. You and the team have just implemented the changes that yourproject wa s developing. Congr at ula tions!

However, your project is not qu ite over yet.


55/81

Page 55

Chapter 7 : Well, how did you go?

So you've planned, tracked, reported and managed the changes to yourproject. You and the team have just implemented the changes that yourproject wa s developing. Congr at ula tions!

However, your project is not qu ite over yet.

Just as after our journey, we tend to reminisce and perhaps bore our friendswith videos and photos of our favourite places, there are a few importantpost-project activities that you and the team need to complete.

In this chapter, we'll discuss the stabilisation process, the post-implementation review and the planning of any additional development onyour product.

Project stabilisation

Once your project has implemented the changes or new product that it was

developing, th ere is typically a period of tim e wher e th e tea m will be requiredto support t he u se of th e product or chan ges in pr ocedur es.

Initially, you and the team would normally be required to provide twoimporta nt post-project ser vices dur ing th is period:

defect repa ir

It is rare that you and team will manage to deliver a perfect outcome.Let's face it - developing a new product or set of procedures is verydifferent to what we are used to doing and is often very complex. Somaking some mistakes is to be expected. As people start using your newproduct or procedur es, th ey will find err ors or defects or problems. Asth ese problems a re ra ised with you a nd t he t eam, you sh ould record wh atthe problem is, who raised it and how you are going to fix them. You willfind that many of the problems can be corrected quickly and depending on


56/81


Page 56

resources, you should implement the problem fix immediately keeping atrack of the effort required to implement the fix. In some cases, the effortrequired to fix the problem could be major. In these cases, you shouldleave these until you have started planning future development orenha ncement s (see lat er in th is cha pter);

consulting

The other service that you and the team will have to provide for peopleusing your project's outcomes will be providing advice and consultancy.Some of th e issues raised with your team will not be errors in t he productitself but rather mis-understandings resulting from ineffective educationand documentation on how to use the new product or service changes. Inmost cases, you'll be able to answer these questions over the phone. Aswith defects, you and the team should record who called, what was theproblem, how long did it take you to resolve the query and are there anyfollow-up actions required?

Depending on t he size of the changes th at your project h as implemented, theproject st abilization period would genera lly ra nge from 1 week to a mont h.

Post-implementat ion review

As shown in Figure 24, the new product or service should eventually becomerelatively stable and established as part of the way of doing things. Once younotice that the level of defects and consultancy are dropping, you and theteam should begin planning to conduct a formalised review of how well yourproject wen t.

Whereas in your tr avels, th e evaluat ion of how your jour ney went tends to beinformal and ad-hoc, in project work, it is very important to review and

document th e successes an d failur es in your project.


57/81


Page 57

Fig. 24 - Project stabilisation pattern

The conduct of a Post-implementation Review or PIR (for those who likeacronyms) is a normal project management activity. It serves a number of purposes :

it m easur es success

Your organisation would have invested your time and, in many projects,substa nt ial investment in equipment t o ru n t he project. It is import an t forthe team to determine how well the project met its Business Case(particularly the objectives, costs and any benefits that the team andsponsor identified at the beginning). If you planned and managed yourproject as we've described in this book, you should have a Business Casethat can be the basis for the review. In general, the process would involvea series of interviews and, if appropriate, surveys of the people impactedby th e project;

it pr ovides a vehicle for lea rn ing

You a nd your team will have learn t m an y things t hr oughout your project.It is important that, before you all move back to other work, you shouldhave a chance to stop and document the things that you picked up on the

Defect Repair

Post-implementationReview

Consulting

Implementation


58/81


Page 58

way. Typically, you would be interested in how well your estimates weremade, what risks occurred and what other factors did you miss. Bywriting these down, you can give other teams about to undertake otherprojects a cha nce to avoid your mist ak es an d gain from your successes;

it ma rks th e end of th e project

This is a personal factor. In many cases, the team will experience a feelingof anti-climax after the project has implemented the changes. This feelingis to be expected after all the har d work a nd sweat a nd tea rs th at you andthe team would have put into the project. The conduct of a Post-implemen ta tion Review provides a good psychological en d t o the project asth e tea m will have a clear pictur e of how well th ey really did.

In a PIR, ther e ar e two things tha t you a re reviewing. The first is th e productand the second is the process. In reviewing the product, you would focus onthings such as whether the product met the clients' and sponsor'srequirements; how well has it been accepted by the people impacted by thecha nges and h ow well is it ru nn ing in th e business place. The form in Figure25 could be used a s a ba sis for su rveying the var ious u sers of th e product.


59/81


Page 59

Fig. 25 - Post-implemen ta tion Review form - Produ ct

The review of the process is really about how well did you manage theproject. This component of the review would focus on your estimates, risk management, change management, communication with stakeholders and soon. The form in Fi

5073662 the Busy Persons Project Management Book

Documents

Transcript of 5073662 the Busy Persons Project Management Book