The TenStep Project Management Process

8/3/2019 The TenStep Project Management Process

1/37

The TenStep Project Management Process (TenStep) is

designed to provide the information necessary to

successfully manage projects of all kinds. On many

project management sites you are sent to links to order

books. On others, you find a professor's notes from a

college class.

On this website you will find what you need to be a

successful project manager, including a step-by-step

approach, starting with the basics and getting as

sophisticated as you need for your particular project.

Welcome the Newest TenStep Licensed Companies for

December 2002

WyethM Solutions Group Ltd.

Moraine Park Technical CollegeCento Sharp ConsultingCity of Hamilton, Ontario

See more companies here

TheTenStep Project Management Processis a methodology for managing work as a project. It is

designed to be as flexible as you need to manage your

project. For instance, it may not make sense to spend a

lot of time on risk management for a project that is 500

hours and similar to many projects that were done

before. That does not imply that you ignore potentialrisks - just that you do not spend as much time as you

might on another project - say one where you were

implementing new technology.

You are visitor

since June 2001

Total page views for December 200,968!

Advertise with us!

In Alice's Adventure in Wonderland, the king says to Alice "Begin at the beginning,and then go 'til you come to the end; then stop". Those words can also describe aproject. We must only agree on what the beginning and the end mean for eachproject. Regardless of the nature of the work, project management processes helpdefine the beginning and the end, as well as provide the framework for managingall the work in the middle.

Project management refers to the definition and planning, and then thesubsequent control and conclusion of a project. Before we even begin, let's firstrecognize that all projects need some level of project management. You are doingit today - even if it is in your head. The larger the project and the more complex itis, the more there is a need for a more formal, standard, structured process. Youmay be able to manage a project of two people for 200 hours in your head.However, you cannot manage a project of five people and 1000 effort hours thesame way. A project of ten people with 5000 effort hours needs more formalmanagement and a project of 20 people and 20,000 hours needs even more.

Obviously there is a cost to the effort associated with project management. Let'sfirst convince ourselves of the benefits that will be obtained, then review somebasic assumptions and caveats and finally get an overview of how the TenStep

Project Management Process works.

0.0.1 The Value of Project Management

0.0.2 Assumptions

0.0.3 Caveats

0.0.4 TenStep Process Overview

0.0.5 TenStep Principles

0.0.6 Overall TenStep Process Flow Graphic

1
http://www.tenstep.com/98.7LookWhoisUsingTenStep.htmhttp://tenstep.com/90.9TenStepWebsiteStats.htmhttp://www.tenstep.com/92.4AdvertiseonTenStep.htmhttp://www.tenstep.com/0.0.1HomeValue.htmhttp://www.tenstep.com/0.0.2HomeAssumption.htmhttp://www.tenstep.com/0.0.3HomeCaveats.htmhttp://www.tenstep.com/0.0.4HomeProcessOverview.htmhttp://www.tenstep.com/0.0.5HomePrinciples.htmhttp://www.tenstep.com/0.0.6TenStepProcessFlow.htmhttp://www.tenstep.com/98.7LookWhoisUsingTenStep.htmhttp://tenstep.com/90.9TenStepWebsiteStats.htmhttp://www.tenstep.com/92.4AdvertiseonTenStep.htmhttp://www.tenstep.com/0.0.1HomeValue.htmhttp://www.tenstep.com/0.0.2HomeAssumption.htmhttp://www.tenstep.com/0.0.3HomeCaveats.htmhttp://www.tenstep.com/0.0.4HomeProcessOverview.htmhttp://www.tenstep.com/0.0.5HomePrinciples.htmhttp://www.tenstep.com/0.0.6TenStepProcessFlow.htm


2/37

0.0.8 Comparison of TenStep to the PMBOK

For general information on the structure of this website, you may want to refer totheSite Map. If you see a term you do not understand, hopefully you will find the

definition in the Glossary. And, if you have any feedback, please drop a note ontheFeedback page.

Now ..... Start at Step 1.0, and let the games begin!

0.0.1 The Value of Project Management

There are some companies that have built reputations for being able toconsistently manage projects effectively. However, the vast majority of

organizations have a more spotty reputation. Does your organization have any ofthe following characteristics?

Projects completed late, over budget, or not meeting the functionalityrequirements of your client

Weak standard processes and techniques used inconsistently by projectmanagers

Project management is reactive, and not seen as providing value

The time required to manage projects proactively is not built into theworkplan, since it is considered 'overhead'

Projects are 'successful' in spite of a lack of planning and project

management, though heavy stress and overtime work throughout the lifecycle.

Good project management discipline is the way to overcome these shortcomings.Having good project management skills does not mean you have no problems. Itdoes not mean that risks go away. It does not mean that there are no surprises.The value of good project management is that you have standard processes inplace to deal with all contingencies.

Project management processes and techniques are used to coordinate resourcesto achieve predictable results. However, it should be understood up front thatproject management is not totally a science, and there is never a guarantee of

success. Since projects involve people, there is always complexity and uncertaintythat cannot be absolutely controlled. Project management is also partly an artthat requires flexibility and creativity, especially in the management of people.

Project management is a science in that it relies on proven and repeatableprocesses and techniques to achieve project success. It is an art because it has alot to do with managing and relating to people, and requires intuitive skills toapply in situations that are totally unique for each project. A good projectmanagement methodology provides the framework, processes, guidelines andtechniques to manage the people and the workload. A good methodologyincreases the odds of being successful, and therefore provides value to theorganization, project and the project manager.

The value proposition for project management goes something like this. It takestime and effort to proactively manage a project. This cost is more than made upfor over the life of the project by:

2
http://www.tenstep.com/0.0.8HomeCompareTenSteptoPMBOK.htmhttp://www.tenstep.com/90.2SiteMap.htmhttp://www.tenstep.com/90.2SiteMap.htmhttp://www.tenstep.com/90.1Glossary.htmhttp://www.tenstep.com/92.2Feedback.htmhttp://www.tenstep.com/92.2Feedback.htmhttp://www.tenstep.com/0.0.8HomeCompareTenSteptoPMBOK.htmhttp://www.tenstep.com/90.2SiteMap.htmhttp://www.tenstep.com/90.1Glossary.htmhttp://www.tenstep.com/92.2Feedback.htm


3/37

Resolving problems more quickly

Not working in areas that are outside of the scope of the project

Resolving future risk before the problems occur

Communicating and managing expectations with clients, team members

and stakeholders more effectively Building a higher quality product the first time.

People who complain that project management is a lot of 'overhead' forget thepoint. Your project is going to face issues. Do you want to proactively resolvethem or figure them out as you go? Your project will face potential risks. Do youwant to try to resolve them before they happen, or wait until the problems arise?Are you going to communicate proactively or deal with conflict and uncertaintycaused by lack of project information? Are you going to manage scope or dealwith cost and deadline overruns caused by doing more work than your budgetcovers? Are you going to build quality into your process, or fix problems laterwhen they will be more costly to resolve?

The characteristics of the project are not going to change whether you use aformal project management process or not. What changes is how the events aredealt with when the project is in progress. Are they dealt with haphazardly andreactively, or proactively with a smoothly running process?

After reading this section so far, you might wonder why everyone does not utilizegood project management techniques. Or you might think about yourself. Whyaren't you using them? There are probably a couple reasons.

Good project management requires an upfront investment of timeand effort.Many people consider themselves to be 'doers'. They might not be as

comfortable with their planning skills. Many times there is a tendency todiscuss a problem, and then go out and fix it. This works when you have afive-hour change request. It doesn't work on a 5,000 hour project. Resistthe urge to jump right in. The project will complete sooner if you properlyplan it first, and then have the discipline to manage the project effectively.

Your organization is not committed.It's hard to be a good project manager in an organization that doesn'tvalue project management skills. For instance, if you take the time tocreate a Project Definition document, and your client asks why you werewasting your time doing it, then you probably are not going to be veryexcited about the planning process on your next project. To be effective,the entire organization must support a common project management

process. You don't know how to.

You may find that the lack of project management processes is not amatter of will, but a matter of skill. Sometimes people are asked tomanage projects without the training or the experience necessary. In thosecases, they struggle without the right tools or training to manage projectseffectively.

Senior managers thinks that project management is a tool.When you discuss project management with some managers, they initiallythink you are trying to implement a tool that allows you to be a betterproject manager. Actually, if it were a tool, you might have more luckconvincing them of the value. Even though some aspects of project

management, like the creation and management of the workplan, mayutilize a tool, that is not where the value of project management is. When

3


4/37

you start talking about processes, best practices and templates, somemanagers immediately start to think about overhead, delay and fluff. Likesome project managers, they fail to immediately connect on the value thata methodology brings with it.

You may have been burned (or buried) in the past.A common criticism of methodology is that it is cumbersome, paperintensive and takes too much focus away from the work at hand.Sometimes this criticism is a feature of the first bullet point above. Othertimes, it is a legitimate concern, caused by not scaling the methodology tothe size of your project. For instance, if you were required to develop afifteen page Project Definition document even if your project is only 250hours, you may have been turned off. However, this is not usually amethodology problem as much as it is a misapplication of themethodology.

There is a fear of control from team members.Many people like to be able to do their jobs creatively and with a minimumof supervision. They fear that formal project management techniques willresult in tight controls that will take the creativity and fun out of the work.To a certain extent they are right. However, common processes andprocedures eliminate some of the creativity in areas where you probablydon't want it in the first place.

There is a fear of the loss of control from management.If you really want to effectively implement a project managementdiscipline at your company, you must give a level of control and authorityto the project manager. Some organizations, and middle managersespecially, do not want to lose that control. They may want projectmanagers to coordinate the projects, but the manager wants to make allthe decisions and exercise all the control. Formal project management willnot be possible in organizations where this fear is prevalent.

Some of these fears are natural and logical, while others are emotional andirrational. Although these may be reasons to be hesitant about using formalproject management, they must be overcome. The bottom line on projectmanagement is this - if the result of project management was that projects wouldcomplete slower, cost more and have poor quality, it would not make sense to useit. In fact, the opposite is true - using sound project management techniques andprocesses will give you a higher likelihood that your project will be completed ontime, within budget and to an acceptable level of quality.

That being said, when you use a project management process, be smart. Don'tbuild the project management processes for a ten million dollar project if yourproject is only ten thousand dollars. Consider all aspects of how to manage aproject, and build the right processes for your specific project.

Options for Obtaining a Methodology

To successfully implement a project management methodology, first convinceyourself that there is value if the process is applied and utilized correctly. In fact,all projects use a methodology of processes, procedures and templates. If youdon't think you have one, it really means that you have a poor and informal one.

If you need a good project management methodology, there are two majorsources.

1. Build one yourself. You can build a custom methodology that perfectlyreflects the philosophy and best practices of your organization. Manycompanies continue to do this today.

4


5/37

2. Buy one. If you build a methodology, you might be surprised to learn that itultimately looks similar to most other project management methodologies thatpeople use. No matter how you structure it, you still need to plan, build aworkplan, manage scope and risks, communicate, etc. Therefore, manycompanies chose an option to buy or license a pre-existing methodology.These pre-built methodologies usually have everything your organization

needs to be successful.

There is also the hybrid option of purchasing a methodology and then customizingit to meet the specific needs of your organization. This gives you some of thebenefits of option 1, while also taking less time, which is the major benefit ofoption 2.

0.0.2 Assumptions

This page describes some assumptions that were made that will put the Ten Stepprocess into better perspective.

The methodology is written with the project manager as the intendedaudience. In many cases, the name 'project manager' is specificallymentioned. In other cases, the content may say 'you' or 'your'. Theassumption is that 'you' (the reader) are a project manager. Obviously,anyone can read and apply the material. But remember it is writtenspecifically for the project management role.

It is assumed for the purposes of the TenStep process that the necessaryfunding and staffing have been approved for the project. Everyorganization has some process that they use to surface ideas, prioritizethem and fund them. At the point in time when a project is being formallydefined and a project manager has been assigned, it is assumed that thebusiness justification, funding and resource approval process has alreadybeen completed.

It is important to recognize that the ten steps of the TenStep methodologydo not imply a sequential progression. It is true that you must define andplan the project before you can manage it. So, steps 1.0 and 2.0 would bedone before the rest. However, the applicable activities in steps 3.0through 10.0 are done in parallel. This means that a project manager willbe managing the workplan (step 3.0), managing scope (step 5.0),managing quality (step 9.0), etc., all through the project.

The higher steps of the TenStep process do imply a higher level of project

management sophistication. For instance, smaller projects do notnecessarily need to manage documentation (step 8.0) since a small projecttypically does not have enough documentation to get messed up. Likewise,the work required to manage quality (step 9.0) and manage a metricsprocess (step 10.0) normally mean that you dont do as much in thoseareas for small and medium sized projects.

A lively discussion can occur around the question of exactly when aproject starts. Some say it starts whenever the idea surfaces for the work.Others say a project starts when the funding is approved. Another idea isto officially start the project when the Project Definition document iscompleted.

For the purposes of this methodology, the project officially begins

when a project manager is assigned. Typically the first job of theproject manager is to formally define the work using a Project

5


6/37

Definition document, and build the workplan. This definition for theproject start time still holds even if the formal project managerdoes not complete the Project Definition and workplan. Rememberthat project management is a role. Whoever completes the ProjectDefinition and workplan is filling the role of the project manager,even if another person is assigned to the formal role at a later time.

0.0.3 Home / Caveats

This page describes some disclaimers and caveats to keep in mind when usingthis site.

This website was created using Microsoft FrontPage. Therefore, the sitecan be viewed best using Internet Explorer. Although the site can beviewed with Netscape, it is not quite as clean and the formatting is notalways consistent.

TheTenStep Project Management Process is designed to be applicable to

all projects, whether you are building a house, a circuit board or acomputer application. After all, all projects deal with planning, managingissues, scope, risk, etc. However, because the background of the author isin software development, you may see some particular reference orexample that is software related (for instance, a suggested metric forsystem response time). In these cases, just substitute a comparableexample that is applicable for your project (like circuit board speed).

This methodology and website are designed to provide a large degree ofvalue, while also being as concise as possible. After all, we want to avoidturning TenStep into one of those methodologies with thousands of pagesthat arent applicable to most projects. There is much more informationthat can be written for each of the steps in the process. For instance, there

are entire books about the risk management process alone. Building aworkplan is also the subject of many five-day classes. It is not the purposeof this website to provide an exhaustive and totally comprehensiveamount of information on each step.

TenStep recognizes that there are other project manager skills that arerequired to be successful on a project, including soft skills. A projectmanager should be a good verbal and written communicator, have goodinterpersonal skills, good listening skills, leadership skills, etc. TheTenStepProject Management Process does not address these important types ofpersonal skills. (In other words, they are out of scope for this process.)TenStep focuses on process management, not people management.However, the TenStep premium libraries do contain information and adviceon people management.

6


7/37

This project management methodology is an umbrella under which the restof the project work gets done. Remember that project management is thething that facilitates a project being successful - it is not the project itself.Regardless of the type of work, it typically follows a life cycle that includesanalysis/business requirements, design, construct/test, implement. Again,while recognizing the importance of understanding the process needed to

produce the project deliverables, this area is outside the scope of thiswebsite.

Some methodologies include the analysis work as part of the projectmanagement process. TheTenStep Project Management Processincludes enough high-level analysis so that the Project Definition documentcan be prepared. Otherwise, the formal analysis/business requirementsphase is considered part of the project life cycle, and is out of the scope ofthe project management process.

Similarly, some methodologies include work with vendors and contracts tobe part of the project management process. TheTenStep ProjectManagement Process considers contract and vendor approvals,searches, evaluations, etc. to be a part of the project activities, not projectmanagement. In many organizations, this work is done by a separatePurchasing or Legal department. Although the project manager should beknowledgeable in this area, it is not considered a core projectmanagement skill in the TenStep process. Of course, vendors are going tointroduce risks, issues, scope change, quality concerns, etc. So this projectmanagement process can still be used to manage these aspects of therelationship.

0.0.4 Process Overview

The TenStep Project Management Process is a scalable process based on thesize of the project. All of the basic Ten Step processes provide guidance based onwhether the project is small, medium or large. Each organization that utilizes TenStep needs to determine what criteria it will use to classify projects. Ten Step usesthree basic criteria for determining overall project size.

The first is the estimated effort of the project. The general guidelines utilized byTen Step are as follows:

Size Effort Hours

Small 1-250 hours

Medium 251 - 5000 hours

Large over 5000 hours

Again, in your company, the effort hours for categorizing project may be different.However, in general, the larger the project, the more structure and formality youwant in the project management process.

The second factor is the experience level of the project manager. If the projectmanager is very experienced, then you might allow them to manage largerprojects with less rigor, or at least up to a higher threshold. On the other hand,you may ask an inexperienced project manager to manage a 2000 hour project asif it was a large one, since they may need more structure.

7


8/37

The third factor is the complexity and business criticality of the project. Forexample, you may want to manage a 1000 hour project as if it were large,because the project is extremely critical to the business. Or, you may want tomanage a 500 hour project as a small one because you have managed two similarprojects before and therefore it seems to be low risk.

Next, start at Step 1.0 of theTenStep Project Management Process - Define theProject. Notice that there are various levels of detail needed for project definition,depending on the size of your project. Define your project based on theinformation described. It is a good practice to review all of the material for allthree project sizes, because you may find other material that you want toincorporate into your particular project.

Do the same for Step 2.0 - Build the Workplan, Step 3.0 - Manage the Workplanand Step 4 - Manage Issues. Start by understanding the recommendations foryour sized project, and then add any activities from the other sized projects thatwill help your project. For the most part, all projects should follow the processes inSteps 1.0 through 4.0.

Now on to Step 5.0 - Manage Scope. Everything you have read so far is stillapplicable, but there is an additional element regarding scope management. Onlarger projects, it is not only important to be more rigorous managing scope, butyou must also do a more thorough job of defining scope. So, you will see newinformation added to the Step 1.0 - Define Project process. That is why you needto categorize your project into small, medium and large ahead of time. In somecases, the higher level project management processes also require more rigor inthe early definition and planning processes.

The rest of theTenStep Project Management Process works the same way.

As described in the Assumptions Section, it is important to recognize that the tensteps of the TenStep methodology do not imply a sequential progression. It is truethat you must define and plan the project before you can manage it. So, steps 1.0and 2.0 would be done before the rest. However, the applicable activities in steps3.0 through 10.0 are done in parallel. This means that a project manager will bemanaging the workplan (step 3.0), managing scope (step 5.0), managing quality(step 9.0), etc., all through the project.

The higher steps of the TenStep process do imply a higher level of projectmanagement sophistication. For instance, smaller projects do not necessarilyneed to manage documentation (step 8.0) since a small project typically does nothave enough documentation to get messed up. Likewise, the work required tomanage quality (step 9.0) and manage a metrics process (step 10.0) normally

mean that you dont do as much in those areas for small and medium sizedprojects.

As always, review the content of each step for each project size. Then determinewhat activities make sense for your project. For instance, you may have a largeproject, but it may make sense to manage communication (Step 6.0) as if youwere a medium project. You may have a large project, but you may not need togather many metrics. In that case you could gather metrics (Step 10.0) as if youwere a small project.

8


9/37

0.0.5 Home / Ten Step Principles

The following represent a set of guiding principles of theTenStep ProjectManagement Process, and are reflected in all the subsequent content.

1.

A project management process must be flexible and scalable, based on the size of the underlying

project. TenStep refers to this concept as "small methodology for small projects, large

methodology for large project". (Scalability refers to the level of complexity of the project

management processes, as well as the time and focus applied to them.)

2.

TheTen Step Project Management Process is designed to be applicable to allprojects, whether you are building a house, a circuit board or a computerapplication. The Ten Step process can also be applied regardless of the projectlife-cycle methodology used (Waterfall, Rapid Application Development (RAD),Agile, etc.) All projects have common needs to manage scope, risk, issues,quality, etc.

3.Projects must be managed proactively, regardless of the size. Project managers that wait for things

to happen most often get into trouble.

4. A successful project normally requires a partnership between the project team and the client. Theproject is at higher risk of failure without active participation from the client.

9


10/37

5.

Project management processes must be established up-front, and understood by the project team

and the client. Most processes require the involvement of multiple members of the client and

project team.

6.

Project managers must have a sufficient level of authority to be successful. If the project manager

is responsible for the delivery of the project, yet they cannot make key decisions needed to manage

the project, they will not be successful.

0.0.6 Ten Step Process Flow

As described in the Assumptions Section, it is important to recognize that the tensteps of the TenStep methodology do not imply a sequential progression. It is truethat you must define and plan the project before you can manage it. So, steps 1.0

and 2.0 would be done before the rest. However, the applicable activities in steps3.0 through 10.0 are done in parallel. This means that a project manager will bemanaging the workplan (step 3.0), managing scope (step 5.0), managing quality(step 9.0), etc., all through the project.

The higher steps of the TenStep process do imply a higher level of projectmanagement sophistication. For instance, smaller projects do not necessarilyneed to manage documentation (step 8.0) since a small project typically does nothave enough documentation to get messed up. Likewise, the work required tomanage quality (step 9.0) and manage a metrics process (step 10.0) normallymean that you dont do as much in those areas for small and medium sizedprojects.

10
http://www.tenstep.com/0.0.2HomeAssumption.htmhttp://www.tenstep.com/0.0.2HomeAssumption.htm


11/37

11


12/37

0.0.8 Comparison of Ten Step to thePMBOK

Every methodology has its own way of laying out the processes, procedures, best

practices and templates required to successfully manage projects. If you look at themin more detail, you start to see many similarities. Differences are present as well, not

so much because of major disagreements, as much as differences in emphasis. For

instance, there are some methodologies that include the gathering of business

requirements as a project management process. The TenStep approach recognizes the

value of gathering business requirements, but considers it part of the project itself, not

a part of the project management umbrella. If a large body of work is broken down

into multiple phases, one entire project might be the Analysis Phase, and another

project might be the Design and Construction Phase. In the second project, there

would be no need to gather business requirements at all.

One of the recognized standard project management methodologies is the ProjectManagement Body of Knowledge (PMBOK), which is the standard put forward bythe Project Management Institute (PMI). The PMBOK contains a lot of valuableinformation, and includes most all of the processes that TenStep contains.However, there is a difference in the packaging and emphasis. In the opinion ofTenStep, Inc., the PMBOK provides a basic foundation for understanding how tomanage work as a project, but is not necessarily a methodology that you can taketo manage a project directly. For instance, there is information, but noprocedures. There are definitions, but not necessarily best practices ortechniques. There are outputs, but no deliverable templates.

On the other hand, there is nothing that is published in the TenStep Project

Management Process that directly contradicts the PMBOK either. Since manyreaders of TenStep are familiar with the PMBOK (and many are PMPs) this

section provides a mapping of the knowledge areas and project management

processes within the PMBOK, with the corresponding processes within the TenStep

Project Management Process.

12


13/37

* This process mapping reflects the PMBOK 2000 edition.

Project Management Body of

Knowledge (PMBOK)

Ten Step Project Management

Process4. Project IntegrationManagement

4.1 Project Plan Development 1.0 Define The Work2.0 Build the Workplan

4.2 Project Plan Execution This covers some aspects of Ten Step 3.0through 10.0 as far as the overallmanagement of the project. The activitiesin PMBOK 4.2 associated with the actualproject work are not considered a part ofthe Ten Step Project Management

Process. They are considered part of theproject work itself.

4.3 Integrated Change Control 5.0 Manage Scope Change8.0 Manage Documents10.0 Manage Metrics

5. Project ScopeManagement

5.1 Initiation The PMBOK project approvalprocess occurs before TenStep 1.0

Define the Work begins. The rest ofthe Initiation Process maps to 1.0Define the Work.

5.2 Scope Planning 1.0 Define the Work, specificallydefining scope in the ProjectDefinition.

5.3 Scope Definition 2.0 Build the Workplan

5.4 Scope Verification 1.0 Define the Work, specificallygaining approval of the Project

Definition5.5 Scope Change Control 5.0 Manage Scope

6. Project TimeManagement

6.1 Activity Definition 2.0 Build the Workplan

6.2 Activity Sequencing 2.0 Build the Workplan

6.3 Activity Duration Estimating 2.0 Build the Workplan

6.4 Schedule Development 2.0 Build the Workplan

6.5 Schedule Control 3.0 Manage the Workplan

13


14/37

7. Project Cost Management

7.1 Resource Planning 2.0 Build the Workplan

7.2 Cost Estimating 2.0 Build the Workplan

7.3 Cost Budgeting 2.0 Build the Workplan7.4 Cost Control 3.0 Manage the Workplan

8. Project QualityManagement

8.1 Quality Planning 1.0 Define the Work9.0 Manage Quality

8.2 Quality Assurance 9.0 Manage Quality

8.3 Quality Control 9.0 Manage Quality

9. Human ResourcesManagement

9.1 Organizational Planning 1.0 Define the Work project levelstructure, within the context oforganizational structure

9.2 Staff Acquisition 2.0 Build the Workplan in regardsto assigning project resources

9.3 Team Development These soft-skills are not a part of theTenStep process, but are

commented on widely in theDownload Library for Licensed Users

10. CommunicationsPlanning

10.1 Communications Planning 6.0 Manage Communication

10.2 Information Distribution 6.0 Manage Communication

10.3 Performance Reporting 6.0 Manage Communication3.0 Manage the Workplan

10.4 Administrative Closure Not a part of the base TenStepProcess, but included in the 20.0Related Topics. Project closure isconsidered part of the project -related to project management, butnot a core component.

11. Project RiskManagement

11.1 Risk Planning 1.0 Define the Work7.0 Manage Risks

11.2 Risk Identification 1.0 Define the Work7.0 Define the Risks

14


15/37

11.3 Qualitative Risk Analysis 1.0 Define the Work7.0 Manage Risks

11.4 Quantitative Risk Analysis 1.0 Define the Work7.0 Manage Risks

11.5 Risk Response Planning 1.0 Define the Work7.0 Manage Risks

11.6 Risk Response Control 7.0 Manage Risks

12. Project ProcurementManagement

12.1 Procurement Planning12.2 Solicitation Planning12.3 Solicitation12.4 Source Selection

12.5 Contract Administration12.6 Contract Closeout

Procurement is not emphasized inTenStep because of the belief thatthis tends to be driven by a separateProcurement / Contracts

Department. The project managermay execute parts of the process,but they do not own the process.There is some information in 20.0Related Topics.

Other Other

Issues management is not anemphasis of the PMBOK.

4.0 Manage Issues

Document management is

mentioned as a part of 4.3Overall Change Control, but isnot emphasized

8.0 Manage Documents

1.0 Define the Work

How many times have you heard about or

been involved in a project that failedmiserably? Or perhaps it just was not as

successful as it needed to be. Did you ever

spend time looking back to see what

caused the project to go wrong.

*** TenStep Licenses ***Get your entire organization utilizing the TenStep Project

Management Process as your company methodology.

Consultant and instructor licenses available as well.

If you did, chances are that you will have

said, "You know, we should have spent

more time planning." Most projects have

deadlines, and it seems they are getting

shorter and shorter.

Join the growing list of project managers receiving the Project

Management Tip of the Week.

** Sign-Up Now **

15
http://www.tenstep.com/98.2TenStepLicenses.htmhttp://www.tenstep.com/98.4Sign-Up.htmhttp://www.tenstep.com/98.4Sign-Up.htmhttp://www.tenstep.com/98.2TenStepLicenses.htmhttp://www.tenstep.com/98.4Sign-Up.htmhttp://www.tenstep.com/98.4Sign-Up.htm


16/37

Hitting aggressive deadlines puts pressure

on the project manager to start the project

as soon as possible. However, before the

project work begins, there needs to be

time spent in up-front planning to make

sure that the work is properly understood

and agreed to. This is not wasted time or'overhead' time. This is the time the

project manager spends ensuring that the

project team and the client have common

perceptions of what the project is going to

deliver, when it will be complete, what it

will cost, who will do the work and how

the work will be done.

At the end of a difficult project, the

benefits of planning might be obvious.

But, the benefits are known ahead of time

as well. At a high-level, the benefitsinclude:

Understanding and gaining agreement on project objectives, deliverables,

scope, risk, cost, approach, etc. (from the Project Definition).

Determining if the original business case is still valid. For instance, a project

that requires 10,000 effort hours might make business sense. If the more

detailed planning process results in a more refined estimate of 20,000 hours,

the project may not make business sense any more.

Making sure the resources you need are available when you need them.

Providing a high-level baseline, from which progress can be compared.

Validating the processes used to manage the project ahead of time with the

client.

It should make sense that small projects need a shorter planning cycle, and largerprojects need a longer planning cycle. The effort required to plan the projectdepends on the amount of information, and the level of detail, that needs to beunderstood and documented. The duration required to define the work dependson the length of time necessary to discover and document the information, as wellas the time required to gain agreement and approval from the client. At times, theproject manager can get frustrated because of the difficulty in gaining agreementwith the client on scope, timeline and cost. But that is exactly the reason thiswork is done ahead of time. Think of the problems you will encounter trying to

gain agreement with the client on scope, schedule or cost when the work hasstarted and the deliverables are actually being produced.

Before the main work on a project begins, a number of items need to be in place.For smaller projects, many of these conditions are met informally or implicitly.However, the larger a project gets, the more important it is that these criteria bemet formally and explicitly.

Client gives approval to begin planning. Normally, implicit approval is

assumed to have occurred for the project to even get this far to begin with.

However, if the project did not have a business case prepared and if it did not

go through a prioritization process, then explicit approval should be soughtbefore project planning begins.

16


17/37

Project is defined. This is documented in the Project Definition, which

contains objectives, scope, assumptions, deliverables, budget, etc. (For

medium or small projects, this might be the Abbreviated Project Definition or

a Service Request.)

Project Workplan is created. A workplan must be prepared and used to

manage the effort. This includes checkpoints, or milestones, when the project

can be evaluated to ensure that it is appropriate to continue.

Client gives approval to begin project. This is signified through a signed,

approved Project Definition. The Sponsor must sign the document to ensure

agreement.

Project Management Procedures are defined and approved - Procedures

must be in place to describe how the project will manage issues,

communication, risks, quality, scope, etc. This is especially true for large

projects, and less important as a project gets smaller.

Project team resources are assigned - You must have the right people tostaff and execute the project. Sometimes valid, approved projects must be

delayed because people with the right skills are not available.

Before we discuss how to define a project, we should be clear on ourunderstanding of what a project is. This will make it clearer when projectmanagement techniques are appropriate. For a general overview, see 1.0.1 Whatis a Project? When you have a sense for what a project is, you can also validateyour understanding of the role of a project manager, at 1.0.2 The Role of a ProjectManager.

Now we can get on with theTenStep Project Management Process.

1.1 Define the Work / Process

1.2 Define the Work / Techniques

1.3 Define the Work / Deliverables

1.4 Define the Work / Additional 'Build Workplan' Activities (Not Applicable)

1.1 Define the Work / ProcessAll projects should spend time up-front in a definition step. For small projects,there is not much additional information needed, and therefore the planningprocess is short. As the project become bigger and bigger, the need to fullyunderstand what is being requested is more important, and gaining agreement onwhat is to be delivered is harder to define. Therefore, more time needs to bespent planning the work. The following webpages describe processes for definingthe work depending on the size of the project,

1.1.1 Small Projects - The Service Request Process

1.1.2 Medium Projects

17
http://www.tenstep.com/1.0.1DefineWork.htmhttp://www.tenstep.com/1.0.1DefineWork.htmhttp://www.tenstep.com/1.0.2DefineWork.htmhttp://www.tenstep.com/1.0.2DefineWork.htmhttp://www.tenstep.com/1.1DefineWork.htmhttp://www.tenstep.com/1.2DefineWork.htmhttp://www.tenstep.com/1.3DefineWork.htmhttp://www.tenstep.com/1.1.1DefineWork.htmhttp://www.tenstep.com/1.1.2DefineWork.htmhttp://www.tenstep.com/1.0.1DefineWork.htmhttp://www.tenstep.com/1.0.1DefineWork.htmhttp://www.tenstep.com/1.0.2DefineWork.htmhttp://www.tenstep.com/1.0.2DefineWork.htmhttp://www.tenstep.com/1.1DefineWork.htmhttp://www.tenstep.com/1.2DefineWork.htmhttp://www.tenstep.com/1.3DefineWork.htmhttp://www.tenstep.com/1.1.1DefineWork.htmhttp://www.tenstep.com/1.1.2DefineWork.htm


18/37

1.1.3 Large Projects - The Discovery Project

1.1.1 Define the Work / Small Projects

Definition of a Small Project

The definition of small projects covers many types of work. In most companies,these small projects are not viewed as projects at all. Your company may callthese enhancements or discretionary requests. For the purposes of the TenStepProject Management Process this work is considered to be a project because itmeets all the criteria of the project definition. The work is unique, has a beginningand end date, results in the creation of a deliverable, etc. Its just that the work issmall and so the project itself is small.

In some organizations, small work efforts are considered a part of the support oroperations organization. There are many work efforts that also fall under support

because they originate with some type of problem or failure to a productionprocess. Sometimes the failure is critical to resolve immediately, and sometimesthe failure is minor and can be allowed to continue unresolved for a long time. Itcan be hard to decide whether a small piece of work should be managed as asupport request, or managed as a small project. The distinction used in TenStep isto look at whether there is discretion in when the work is completed. If a problemarises that requires a fix to be performed quickly, the work is definitely support. Ifa problem arises that can be prioritized and worked on sometime in the future,then it is considered a small project.

In general then, small projects can include the following.

Actual unique work efforts that are clearly projects but have a shortduration and small numbers of effort hours.

Enhancements to existing production processes and systems.

Bugs and errors in production processes that are nuisances, but can bescheduled for resolution at a later time. That is, fixing the problem is alower business priority than other work.

Small process improvements.

Discovery or fact-finding work that may lead to further Service Requests ora project.

Changes to production processes that are the result of legal, tax or

auditing requirements. These requests may not be consideredenhancements, since they do not provide any additional business value.

If work is classified as a discretionary small project, it does not diminish the criticality

or the value of the request. It only means that there is discretion as to when the work

gets done. For example, if a request is important enough, it may push to the top of the

work queue and be started immediately. However, later an even more urgent request

could come up that would require the other request to be put on hold. The nature of

discretionary work is that it is subject to prioritization decisions. This is in contrast to

true support work. If a production process is down, or is producing inaccurate results,

then typically the problem needs to be resolved now, and cannot be stopped because

of a discretionary request.

18
http://www.tenstep.com/1.1.3DefineWork.htmhttp://www.tenstep.com/1.1.3DefineWork.htm


19/37

In general, all small discretionary work can be documented, evaluated and prioritized

through a Service Request Process.

The Service Request Process

In a small project, there is usually not a lot of effort associated with formally

defining the work to be done. However, some work still needs to be done. Theresult of this short definition is a one-to-two page document called a ServiceRequest.

Along with a much shorter project definition activity, the process for assigning thework is different as well. When the work definition for a larger project iscompleted, the project is usually ready to begin. However, for smaller efforts,there may be many more Service Requests than can actually be worked on at anygiven time. Therefore, a process needs to be established for gathering ServiceRequests and assigning them to team members based on client priorities. Sincethere will likely be many Service Requests, it is important to have some way tokeep track of them, and a way to ensure that the higher priority requests arebeing worked on. The following Service Request Process can be used.

1. Client submits the request. The client, with the help of the projectmanager if necessary, completes a simple Service Request form thatdocuments the work requested. Even though the work may be small, theService Request serves as the formal document describing the work to bedone, and contains the appropriate client approvals. A Service Requesttypically contains the work that is requested, the priority of the work andthe business value of the work.

2. Project manager reviews and clarifies. The project manager reviewsthe Service Request to ensure that the work is understood. The projectmanager asks questions of the client if necessary, to clarify what is beingrequested. The project manager must also understand the criticality of the

request and whether any prerequisite work needs to be completed first.3. A high-level estimate is prepared.

If the project manager understands the work wellenough, and if they have the proper level of expertise, theyprovide a high-level estimate of the effort hours andduration and include this information on the ServiceRequest. It is possible that once the client sees theestimated effort, they may change their mind regarding therelative priority. For instance, if the effort is much higherthan they realized, the priority may be lowered. If theestimate is much smaller than they realized, they may raisethe priority higher so that the work can be completed

sooner.

If the project manager cannot estimate the work, theyassign to a team member to create the estimates. If no oneon the team has the time or expertise to create a high-levelestimate, then the estimation process must itself be placedon the backlog. The client must decide if the effort requiredgathering information to create the estimate is of a highenough priority that they are willing to work on it rather thanother Service Requests. This high-level estimate is used forprioritization purposes only. When the work is actuallyassigned, a more detailed estimate can be prepared, ifnecessary.

4. The request is assigned or backlogged. The project manager andclient evaluate the request against the other work that is assigned and on

19


20/37

the backlog. They also review the available capacity and skills on the teamto determine if the work can be started immediately. If the requiredresources are not available, or if the work is of lower priority than otherService Requests, the new request is placed on a backlog list. The backlogcontains all work that has been requested, estimated and prioritized, but isnot assigned to begin yet.

5. Periodically review the backlogged work. The project manager andclient review the backlog on a regular basis. When the priority of a ServiceRequest is high enough and the right resources are available, the work canbe assigned to begin. If a Service Request on the backlog is more criticalthan work that is in-progress, the previously assigned work is placed on-hold, put back on the backlog, or used as filler while the new request isbegun.

6. Revalidate the initial information. When the work is assigned to begin,the person(s) doing the work should validate that the information on theService Request is correct, and that the estimates are accurate. If they arenot, then the new information should be documented and discussedimmediately to see if it will have an impact on the priority. For instance,the client may want to proceed with a small project of 40 hours. However,if the more detailed estimate ends up closer to 80 hours, they may notwant to perform the work at that time. There may be other requests thatare more critical and take less time to complete.

7. Manage the work. Once the work begins, it is managed through theManage the Work processes (Manage scope, communication, risk, etc.)Since the request is small, all of these project management processes areonly utilized as needed. Project Management Procedures are not set up forindividual small projects. Instead, generic procedures are established togovern all the work performed through Service Requests.

8. Close the work. When the work is completed, the client should signify

their approval. The Service Request should then be closed and moved to aclosed queue that tracks these requests for historical purposes.




In some organizations, small work efforts are considered a part of the support oroperations organization. There are many work efforts that also fall under supportbecause they originate with some type of problem or failure to a productionprocess. Sometimes the failure is critical to resolve immediately, and sometimesthe failure is minor and can be allowed to continue unresolved for a long time. Itcan be hard to decide whether a small piece of work should be managed as asupport request, or managed as a small project. The distinction used in TenStep is

20


21/37

to look at whether there is discretion in when the work is completed. If a problemarises that requires a fix to be performed quickly, the work is definitely support. Ifa problem arises that can be prioritized and worked on sometime in the future,then it is considered a small project.







Changes to production processes that are the result of legal, tax orauditing requirements. These requests may not be consideredenhancements, since they do not provide any additional business value.






discretionary work is that it is subject to prioritization decisions. This is in contrast to

true support work. If a production process is down, or is producing inaccurate results,

then typically the problem needs to be resolved now, and cannot be stopped becauseof a discretionary request.




In a small project, there is usually not a lot of effort associated with formallydefining the work to be done. However, some work still needs to be done. Theresult of this short definition is a one-to-two page document called a ServiceRequest.


1. Client submits the request. The client, with the help of the projectmanager if necessary, completes a simple Service Request form that

documents the work requested. Even though the work may be small, theService Request serves as the formal document describing the work to bedone, and contains the appropriate client approvals. A Service Request

21


22/37

typically contains the work that is requested, the priority of the work andthe business value of the work.

2. Project manager reviews and clarifies. The project manager reviewsthe Service Request to ensure that the work is understood. The projectmanager asks questions of the client if necessary, to clarify what is being

requested. The project manager must also understand the criticality of therequest and whether any prerequisite work needs to be completed first.

3. A high-level estimate is prepared.

If the project manager understands the work wellenough, and if they have the proper level of expertise, theyprovide a high-level estimate of the effort hours andduration and include this information on the ServiceRequest. It is possible that once the client sees theestimated effort, they may change their mind regarding therelative priority. For instance, if the effort is much higherthan they realized, the priority may be lowered. If theestimate is much smaller than they realized, they may raise

the priority higher so that the work can be completedsooner.

If the project manager cannot estimate the work, theyassign to a team member to create the estimates. If no oneon the team has the time or expertise to create a high-levelestimate, then the estimation process must itself be placedon the backlog. The client must decide if the effort requiredgathering information to create the estimate is of a highenough priority that they are willing to work on it rather thanother Service Requests. This high-level estimate is used forprioritization purposes only. When the work is actuallyassigned, a more detailed estimate can be prepared, if

necessary.4. The request is assigned or backlogged. The project manager and

client evaluate the request against the other work that is assigned and onthe backlog. They also review the available capacity and skills on the teamto determine if the work can be started immediately. If the requiredresources are not available, or if the work is of lower priority than otherService Requests, the new request is placed on a backlog list. The backlogcontains all work that has been requested, estimated and prioritized, but isnot assigned to begin yet.

5. Periodically review the backlogged work. The project manager andclient review the backlog on a regular basis. When the priority of a ServiceRequest is high enough and the right resources are available, the work can

be assigned to begin. If a Service Request on the backlog is more criticalthan work that is in-progress, the previously assigned work is placed on-hold, put back on the backlog, or used as filler while the new request isbegun.

6. Revalidate the initial information. When the work is assigned to begin,the person(s) doing the work should validate that the information on theService Request is correct, and that the estimates are accurate. If they arenot, then the new information should be documented and discussedimmediately to see if it will have an impact on the priority. For instance,the client may want to proceed with a small project of 40 hours. However,if the more detailed estimate ends up closer to 80 hours, they may notwant to perform the work at that time. There may be other requests that

are more critical and take less time to complete.

22


23/37


8. Close the work. When the work is completed, the client should signifytheir approval. The Service Request should then be closed and moved to aclosed queue that tracks these requests for historical purposes.




In some organizations, small work efforts are considered a part of the support oroperations organization. There are many work efforts that also fall under supportbecause they originate with some type of problem or failure to a productionprocess. Sometimes the failure is critical to resolve immediately, and sometimes

the failure is minor and can be allowed to continue unresolved for a long time. Itcan be hard to decide whether a small piece of work should be managed as asupport request, or managed as a small project. The distinction used in TenStep isto look at whether there is discretion in when the work is completed. If a problemarises that requires a fix to be performed quickly, the work is definitely support. Ifa problem arises that can be prioritized and worked on sometime in the future,then it is considered a small project.







Changes to production processes that are the result of legal, tax orauditing requirements. These requests may not be consideredenhancements, since they do not provide any additional business value.

23


24/37






discretionary work is that it is subject to prioritization decisions. This is in contrast totrue support work. If a production process is down, or is producing inaccurate results,

then typically the problem needs to be resolved now, and cannot be stopped because

of a discretionary request.




In a small project, there is usually not a lot of effort associated with formallydefining the work to be done. However, some work still needs to be done. Theresult of this short definition is a one-to-two page document called a ServiceRequest.


1. Client submits the request. The client, with the help of the projectmanager if necessary, completes a simple Service Request form thatdocuments the work requested. Even though the work may be small, theService Request serves as the formal document describing the work to bedone, and contains the appropriate client approvals. A Service Requesttypically contains the work that is requested, the priority of the work andthe business value of the work.

2. Project manager reviews and clarifies. The project manager reviewsthe Service Request to ensure that the work is understood. The projectmanager asks questions of the client if necessary, to clarify what is beingrequested. The project manager must also understand the criticality of therequest and whether any prerequisite work needs to be completed first.

3. A high-level estimate is prepared.

If the project manager understands the work wellenough, and if they have the proper level of expertise, theyprovide a high-level estimate of the effort hours andduration and include this information on the ServiceRequest. It is possible that once the client sees theestimated effort, they may change their mind regarding therelative priority. For instance, if the effort is much higherthan they realized, the priority may be lowered. If theestimate is much smaller than they realized, they may raisethe priority higher so that the work can be completedsooner.

If the project manager cannot estimate the work, theyassign to a team member to create the estimates. If no one

24


25/37

on the team has the time or expertise to create a high-levelestimate, then the estimation process must itself be placedon the backlog. The client must decide if the effort requiredgathering information to create the estimate is of a highenough priority that they are willing to work on it rather thanother Service Requests. This high-level estimate is used for

prioritization purposes only. When the work is actuallyassigned, a more detailed estimate can be prepared, ifnecessary.

4. The request is assigned or backlogged. The project manager andclient evaluate the request against the other work that is assigned and onthe backlog. They also review the available capacity and skills on the teamto determine if the work can be started immediately. If the requiredresources are not available, or if the work is of lower priority than otherService Requests, the new request is placed on a backlog list. The backlogcontains all work that has been requested, estimated and prioritized, but isnot assigned to begin yet.

5. Periodically review the backlogged work. The project manager andclient review the backlog on a regular basis. When the priority of a ServiceRequest is high enough and the right resources are available, the work canbe assigned to begin. If a Service Request on the backlog is more criticalthan work that is in-progress, the previously assigned work is placed on-hold, put back on the backlog, or used as filler while the new request isbegun.

6. Revalidate the initial information. When the work is assigned to begin,the person(s) doing the work should validate that the information on theService Request is correct, and that the estimates are accurate. If they arenot, then the new information should be documented and discussedimmediately to see if it will have an impact on the priority. For instance,the client may want to proceed with a small project of 40 hours. However,if the more detailed estimate ends up closer to 80 hours, they may notwant to perform the work at that time. There may be other requests thatare more critical and take less time to complete.


8. Close the work. When the work is completed, the client should signifytheir approval. The Service Request should then be closed and moved to a

closed queue that tracks these requests for historical purposes.

1.2 Define the Work / Techniques

Work on the Project Definition and Project WorkplanSimultaneously

There is not necessarily a sequential order between defining the project andbuilding the workplan. That is, you do not have to completely define the project

first and then build the workplan second. Notice that some of the sections of theProject Definition, for instance, cannot be completed without starting to lay out

25


26/37

the overall project workplan. At the same time, you cannot complete the workplanwithout gaining agreement on theProject Definition. For instance, you cannotbuild the workplan without gaining a high-level agreement on deliverables andscope. Defining the project also involves describing an overall project approach,which is needed before the workplan can be completed.

To a certain extent, defining the project and building the workplan need to bedone simultaneously. The two main deliverables, the Project Definition and projectworkplan, should also be developed in parallel. You will find that as you gatherinformation around scope and deliverables, you can start laying out a high-levelworkplan. As you gather more information on the project, you can fill in moredetails on the workplan. When the deliverables, scope, assumptions and approachare complete, you should have enough information to be able to complete a high-level workplan. You can then use the high-level workplan to estimate thenecessary budget, effort and duration - which in turn are used to complete theProject Definition.

Break Large Projects into Smaller Pieces

For the most part, the days of the hundred million dollar project are over. Very

large projects are simply too difficult to manage and execute successfully. Thereare a number of problems with very large projects.

The work is less clear the farther out in the future it is. Large projects areusually always long projects as well, and that makes them very difficult toplan successfully.

Since the future work is less clear, it is harder to make accurate estimatesfor effort, duration and cost.

Business and technical conditions change over time, making planningassumptions in the future very uncertain. The business and technicalcertainties of today can change dramatically over time.

You risk losing organization support if there is a long delay beforedelivering tangible results. It is very difficult to maintain organizationalenthusiasm and support over long periods of time.

It is very difficult to predict resource requirements and availability far intothe future. Again, this gets at the difficulty of estimating accurately as youget further out in the future.

In general, very large efforts are much too difficult and complex to manage as asingle project. The better technique is to break the work down into moremanageable chunks, each of which is considered its own project, with its ownProject Definitionand workplan.

For instance, a long IT development effort can be broken into separate sequentialprojects based on the life cycle. A project is set up for the analysis work. Toward

the end of that project a second project is established, based on what you knowthen, to do the design work. Then a construct/test project is initiated, and finally aproject for implementation. Other large initiatives might be broken up into smallerprojects that might run in parallel. Some large initiatives can have a combinationof smaller projects - some of which must be done sequentially, but others that canbe done in parallel. Each team will work to complete its smaller project, but all thework would be coordinated so that the entire effort is successful.

Set up a Program to Coordinate a Set of Related Projects

If you break down a large effort into a number of related projects, there is still aneed to maintain overall management and coordination. This is the purpose ofsetting up a 'program'. A program is the umbrella structure established to

manage a series of related projects. Each project has a full-time or part-timeproject manager. The program is lead by a program manager. The program does

26


27/37

not produce any project deliverables itself. The project teams produce them all.The purpose of the program is to:

Provide overall direction, guidance and leadership for the projects.

Make sure the related projects are communicating effectively.

Provide a central point of contact and focus for the client and the projectteams.

Determine how individual projects should be defined to ensure all the workgets completed successfully.

The Client May Not Know Enough to Completely Define theProject

Sometimes we place too high an expectation on the amount of foresight andvision that clients have. In many cases, the project manager will go to the clientlooking for answers to help define the project, and the client will not have all ofthe information needed. This happens all the time, and it does not mean that theclient does not know what they are doing. In many cases, especially for large

projects, the client has a vision of what the end results will be, but cannot yetarticulate this into concrete deliverables. They may also not know all of theanswers on scope, risks, project organization, etc.

Based on having less than complete information, the project manager may feelthe need to guess on the details. This is not a good solution. It is better to stateup-front everything that you know, as well as everything that you do not know. Ifyou are asked to come up with estimated effort, cost and duration, you will needto provide a high and low range based on the uncertainty remaining.

If possible, the much better alternative is simply to break the work down into aseries of smaller projects (as described above). Even if the final results cannot beclearly defined, there should be some amount of work that is well defined, whichwill, in turn lead to the information needed for the final solution. You should only

define a project to cover as far as you can comfortably see today. Then define andplan subsequent projects to cover the remaining work as more details are known.

If you are not allowed to break the project into smaller pieces, you should at leastknow enough that you can plan the work for the first 90 days. Again, you plan theshort-term work in more detail, and leave the longer term effort more undefined.Each month you should redefine and plan the remaining work. As you uncovermore and more information, you can plan the remaining work at a more detailedlevel.

Project Organization - Roles and Responsibilities

For small projects, the organization is pretty simple - maybe just the projectmanager and the client / sponsor. The person who is managing the project may

be the only person actually working on the project as well.

However, for large projects, there may end up being an elaborate and formalorganizational structure. You may have team members, an executive sponsor, aproject sponsor, a client manager, a project director, a steering committee,vendors, customers, and others involved. You do not want to get overly complex,but the more people that are involved in the project; the more important it is thateveryone be clear on what their roles and responsibilities are. For example, thelast thing you want is to have people give you direction as if they were thesponsor, when really they may just be management stakeholders. You also dontwant people acting as team members, when really they are stakeholders.

One aspect of defining the project is to define the organization structure and whatthe roles and responsibilities are. Usually the typical roles and responsibilities canbe defined ahead of time for your organization, and then reused as appropriate

27


28/37

from project to project. Many of the common project roles and responsibilities areoutlined in 1.2.2 Define Work / Roles and Responsibilities.

Project Approvals

Once the project has been defined, the project manager should seek formalapproval from the appropriate sponsor and management stakeholders. There are

many ways to gain formal project approval. Like most other activities in theTenStep Project Management Process, a little bit of planning is the key. Forsmall projects, one signature from the main client or Project Sponsor is probablysufficient to show approval of the work to begin. This approval could also be viaemail confirmation. However, it should not be verbal.

For larger projects, ask your manager and the Project Sponsor who should haveexplicit approval of the Project Definition, who should have implicit approval andwho needs to get a copy for informational purposes only. In general, use thefollowing approach as your starting point.

Project Sponsor and key stakeholders. Get an explicit approval. Thisapproval can be a formal signature on a paper copy of the Project

Definition. It could also be an email specifically stating approval. You mightalso have some type of formal workflow approval. The key is that theapproval is explicit and that you save a record of the approval.

Other management stakeholders. Get an implicit approval. Implicitmeans that you assume they approve the Project Definition unless theyget back to you otherwise. You would first send them a soft or hard copy ofthe Project Definition. Let them know you would like them to review thematerial and provide feedback if they are in agreement or if they have anyconcerns. Then give them a date for replying, and let them know that ifyou do not hear back from them before the date, you will assume they aregranting their approval. If they come back to you with concerns, addressthem or take them to the Project Sponsor for resolution.

Other interested parties. Send them a copy of the Project Definition. Letthem know that it is for their information only. You should be available todiscuss any content so that they can better understand the material, butyou are not sending it to them for their approval.

28
http://www.tenstep.com/1.2.2DefineWork.htmhttp://www.tenstep.com/1.2.2DefineWork.htm


29/37

1.3 Define the Work / Deliverables

Size Information Needed

Small

Deliverable: Service Request.

(Note: This is probably a one to two page form. Nothing longer isneeded.)

Service Request Number (optional): This number ties the work to anyother processes or software that needs a tracking number.

Priority (optional): The client's recommendation in terms of high,medium, low.

Project / Application Name: The name of the project that this is for. If this is an

enhancement request, this refers to the existing system.

Scope Statement: Describe the work that is being requested. Be asspecific as possible regarding the new work or enhancements to existingsystem.

Reason for Service Request (Optional): What is the benefit for doingthis work?

Assigned to: Typically include the specific people who will be assigned tothe work. This may not be known up front, but can be filled in when thework is assigned.

Skills Needed (optional): Describes the skills that are needed to fulfill this request.

Estimated Effort Hours and Cost: For a small project, this should bereasonably close. Since there is not a lot of work, there should be fewunknowns that would cause major estimating error. The project manageror a knowledgeable team member can complete the estimate.

Estimated Duration: How long will it take to complete the work once itstarts?

Approval #1 / Date: Client signature to signify that the work on thisrequest can proceed. (Ensures that the client is agreeing that the priorityon this work is high enough that it can start.)

Approval #2 / Date: (Optional) Client signature to signify agreement thatthe solution can be moved to production.

Approval #3 / Date: Client signature to signify work has beensuccessfully completed.

** Find Service Request in Template Library **

29
http://www.tenstep.com/96.2FreeTemplateLibrary.htmhttp://www.tenstep.com/96.2FreeTemplateLibrary.htm


30/37

Medium

(1) Deliverable: Abbreviated Project Definition

Project Overview: States the purpose of the project and why it is being performed.

Scope: Define the deliverables being created by this project and provide some explanation

regarding what the deliverable will look like. See 5.1.1 Defining Scope for more details.

Estimated Effort Hours: Estimate the effort required. Provide information on how the

estimate was prepared, what assumptions were made, etc. For further information, see 2.1.1

Build Workplan / Process / Estimating.

Estimated Cost: Estimate the cost for labor, based on the effort hours. Add any non-labor

expense such as hardware, software, training, travel, etc. For further information, see2.1.1


Estimated Duration: Estimate how long the project will take to complete, once it starts. If

the start date is known, then the end date can be determined here as well. For further

information, see 2.1.1 Build Workplan / Process / Estimating.

Major Assumptions: Assumptions are external events that must occur for the project to be

successful. If it looks more than likely that these events will occur then they should be listed

as assumptions. Assumptions can be identified through the experience of knowing what

activities or events are likely to occur in your organization, through brainstorming sessions

with the clients, stakeholders and team member, and by looking at items that were identified

as low risk in the risk management process. For further information on assumptions, see 7.1.1

Manage Risk / Assumptions.

Major Risks: What external events must occur for the project to be successful? Is there a

good likelihood that any of these events will not occur? If so, then these should be identified

as risks. For further information on risks, see7.1 Manage Risk / Process.

Approvals: Names and titles for the people who need to approve the document. (See 2.2

Define the Project - Techniques for options on how to get approvals.)

** Find Abbreviated Project Definition in Template Library **

(2) Deliverable: Project Management Procedures

This document contains the procedures that will be used to manage the project. It will include

sections on: Issues Management, Scope Change Management, Communication Management,

Risk Management, Sharing Information, Quality Management and Metrics. (Starting points

for these procedures can be found in subsequent steps of this methodology.)

** Find Project Management Procedures in Template Library **

30
http://www.tenstep.com/5.1.1ManageScope.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/7.1.1ManageRisk.htmhttp://www.tenstep.com/7.1.1ManageRisk.htmhttp://www.tenstep.com/7.1ManageRisk.htmhttp://www.tenstep.com/7.1ManageRisk.htmhttp://www.tenstep.com/96.2FreeTemplateLibrary.htmhttp://www.tenstep.com/96.2FreeTemplateLibrary.htmhttp://www.tenstep.com/5.1.1ManageScope.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/2.1.1BuildWorkplan.htmhttp://www.tenstep.com/7.1.1ManageRisk.htmhttp://www.tenstep.com/7.1.1ManageRisk.htmhttp://www.tenstep.com/7.1ManageRisk.htmhttp://www.tenstep.com/96.2FreeTemplateLibrary.htmhttp://www.tenstep.com/96.2FreeTemplateLibrary.htm


31/37

Large (1) Deliverable: Project Definition

Executive Summary: The full Project Definition document may tend to become large and

difficult for the senior managers to digest. Include an Executive Overview for management to

read. The Executive Overview is a summary of the actual Project Definition document. It is

not just an overview of the project.

Project Overview: Add the business benefit of the project. Share any business goals and

objectives that this project is trying to achieve.

Project Objectives: State the objectives that the project will achieve. The project objective

should support the business goals and objectives. The deliverables produced should support

the Project Objectives. For further information on goals and objectives, see1.2.1 Define the

Work / Goals and Objectives.

Project Scope: Define the deliverables being created by this project and provide some

explanation regarding what the deliverable will look like. Also add information as to what the

project will not produce. In other words, what is out of scope? It is very important to be clear

about what things the project could produce, but will not. This will make it much easier tomanage scope change throughout the project. In addition to deliverables, further describe

scope in more specific terms such as:

What data will the project work with and what data is out of scope?

What organizations will be effected and which will not be?

What business processes are in scope and out of scope?

What transactions are in scope and out of scope?

What other projects are impacted and which will be left alone?

Any other in-scope / out-of-scope qualifier that makes sense.

See 5.1.1 Defining Scope for more details.

Estimated Effort Hours: Estimate the effort required. Provide information on how the

estimate was prepared, what assumptions were made, etc. For further information, see 2.1.1


Estimated Cost: Estimate the cost for labor, based on the effort hours. Add any non-labor

expense such as hardware, software, training, travel, etc. For further information, see2.1.1


Estimated Duration: Estimate how long the project will take to complete, once it starts. Ifthe start date is known, then the end date can be determined here as well. For further

information, see 2.1.1 Build Workplan / Process / Estimating.

Assumptions: Assumptions are external events that must occur for the project to be

successful. If it looks more than likely that these events will occur then they should be listed

as assumptions. Assumptions can be identified through the experience of knowing what

activities or events are likely to occur in your organization, through brainstorming sessions

with the clients, stakeholders and team member, and by looking at items that were identified

as low risk in the risk management process. For further information on assumptions, see 7.1.1

Manage Risk / Assumptions.

Major Risks: Risks are future, external events that will cause problems to the project is they

occur. If there is a good likelihood that any of these events will occur then they should beidentified as a risk. If so, then these should be identified as risks. For further information on

31
http://www.tenstep.com/1.2.1DefineWork.htmhttp://www.tenstep.com/1.2.1DefineWork.htmhttp://www.tenstep.com/1

The TenStep Project Management Process

Documents

Transcript of The TenStep Project Management Process