Sunteți pe pagina 1din 37

The TenStep Project Management Process (TenStep) is Welcome the Newest TenStep Licensed Companies for designed to provide

the information necessary to December 2002 successfully manage projects of all kinds. On many project management sites you are sent to links to order Wyeth books. On others, you find a professor's notes from a M Solutions Group Ltd. 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. The TenStep Project Management Process is 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 potential risks - just that you do not spend as much time as you might on another project - say one where you were implementing new technology.
Moraine Park Technical College Cento Sharp Consulting City of Hamilton, Ontario See more companies here

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 a project. We must only agree on what the beginning and the end mean for each project. Regardless of the nature of the work, project management processes help define the beginning and the end, as well as provide the framework for managing all the work in the middle. Project management refers to the definition and planning, and then the subsequent control and conclusion of a project. Before we even begin, let's first recognize that all projects need some level of project management. You are doing it today - even if it is in your head. The larger the project and the more complex it is, the more there is a need for a more formal, standard, structured process. You may 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 the same way. A project of ten people with 5000 effort hours needs more formal management 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's first convince ourselves of the benefits that will be obtained, then review some basic 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

0.0.8 Comparison of TenStep to the PMBOK For general information on the structure of this website, you may want to refer to the Site 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 on the Feedback 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 to consistently manage projects effectively. However, the vast majority of organizations have a more spotty reputation. Does your organization have any of the following characteristics? Projects completed late, over budget, or not meeting the functionality requirements of your client Weak standard processes and techniques used inconsistently by project managers Project management is reactive, and not seen as providing value The time required to manage projects proactively is not built into the workplan, 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 life cycle.

Good project management discipline is the way to overcome these shortcomings. Having good project management skills does not mean you have no problems. It does 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 in place to deal with all contingencies. Project management processes and techniques are used to coordinate resources to achieve predictable results. However, it should be understood up front that project management is not totally a science, and there is never a guarantee of success. Since projects involve people, there is always complexity and uncertainty that cannot be absolutely controlled. Project management is also partly an art that requires flexibility and creativity, especially in the management of people. Project management is a science in that it relies on proven and repeatable processes and techniques to achieve project success. It is an art because it has a lot to do with managing and relating to people, and requires intuitive skills to apply in situations that are totally unique for each project. A good project management methodology provides the framework, processes, guidelines and techniques to manage the people and the workload. A good methodology increases the odds of being successful, and therefore provides value to the organization, project and the project manager. The value proposition for project management goes something like this. It takes time and effort to proactively manage a project. This cost is more than made up for over the life of the project by:

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 the point. Your project is going to face issues. Do you want to proactively resolve them or figure them out as you go? Your project will face potential risks. Do you want 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 uncertainty caused by lack of project information? Are you going to manage scope or deal with cost and deadline overruns caused by doing more work than your budget covers? Are you going to build quality into your process, or fix problems later when they will be more costly to resolve? The characteristics of the project are not going to change whether you use a formal project management process or not. What changes is how the events are dealt with when the project is in progress. Are they dealt with haphazardly and reactively, or proactively with a smoothly running process? After reading this section so far, you might wonder why everyone does not utilize good project management techniques. Or you might think about yourself. Why aren't you using them? There are probably a couple reasons. Good project management requires an upfront investment of time and effort. Many people consider themselves to be 'doers'. They might not be as comfortable with their planning skills. Many times there is a tendency to discuss a problem, and then go out and fix it. This works when you have a five-hour change request. It doesn't work on a 5,000 hour project. Resist the urge to jump right in. The project will complete sooner if you properly plan 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't value project management skills. For instance, if you take the time to create a Project Definition document, and your client asks why you were wasting your time doing it, then you probably are not going to be very excited 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 a matter of will, but a matter of skill. Sometimes people are asked to manage projects without the training or the experience necessary. In those cases, they struggle without the right tools or training to manage projects effectively. Senior managers thinks that project management is a tool. When you discuss project management with some managers, they initially think you are trying to implement a tool that allows you to be a better project manager. Actually, if it were a tool, you might have more luck convincing them of the value. Even though some aspects of project management, like the creation and management of the workplan, may utilize a tool, that is not where the value of project management is. When

you start talking about processes, best practices and templates, some managers immediately start to think about overhead, delay and fluff. Like some project managers, they fail to immediately connect on the value that a methodology brings with it. You may have been burned (or buried) in the past. A common criticism of methodology is that it is cumbersome, paper intensive and takes too much focus away from the work at hand. Sometimes this criticism is a feature of the first bullet point above. Other times, it is a legitimate concern, caused by not scaling the methodology to the size of your project. For instance, if you were required to develop a fifteen page Project Definition document even if your project is only 250 hours, you may have been turned off. However, this is not usually a methodology problem as much as it is a misapplication of the methodology. There is a fear of control from team members. Many people like to be able to do their jobs creatively and with a minimum of supervision. They fear that formal project management techniques will result in tight controls that will take the creativity and fun out of the work. To a certain extent they are right. However, common processes and procedures eliminate some of the creativity in areas where you probably don'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 management discipline at your company, you must give a level of control and authority to the project manager. Some organizations, and middle managers especially, do not want to lose that control. They may want project managers to coordinate the projects, but the manager wants to make all the decisions and exercise all the control. Formal project management will not be possible in organizations where this fear is prevalent.

Some of these fears are natural and logical, while others are emotional and irrational. Although these may be reasons to be hesitant about using formal project management, they must be overcome. The bottom line on project management is this - if the result of project management was that projects would complete slower, cost more and have poor quality, it would not make sense to use it. In fact, the opposite is true - using sound project management techniques and processes will give you a higher likelihood that your project will be completed on time, within budget and to an acceptable level of quality. That being said, when you use a project management process, be smart. Don't build the project management processes for a ten million dollar project if your project is only ten thousand dollars. Consider all aspects of how to manage a project, and build the right processes for your specific project.

Options for Obtaining a Methodology


To successfully implement a project management methodology, first convince yourself 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 you don'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 major sources. 1. Build one yourself. You can build a custom methodology that perfectly reflects the philosophy and best practices of your organization. Many companies continue to do this today.

2.

Buy one. If you build a methodology, you might be surprised to learn that it ultimately looks similar to most other project management methodologies that people use. No matter how you structure it, you still need to plan, build a workplan, manage scope and risks, communicate, etc. Therefore, many companies 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 customizing it to meet the specific needs of your organization. This gives you some of the benefits of option 1, while also taking less time, which is the major benefit of option 2.

0.0.2 Assumptions
This page describes some assumptions that were made that will put the Ten Step process into better perspective. The methodology is written with the project manager as the intended audience. In many cases, the name 'project manager' is specifically mentioned. In other cases, the content may say 'you' or 'your'. The assumption is that 'you' (the reader) are a project manager. Obviously, anyone can read and apply the material. But remember it is written specifically for the project management role. It is assumed for the purposes of the TenStep process that the necessary funding and staffing have been approved for the project. Every organization has some process that they use to surface ideas, prioritize them and fund them. At the point in time when a project is being formally defined and a project manager has been assigned, it is assumed that the business justification, funding and resource approval process has already been completed. It is important to recognize that the ten steps of the TenStep methodology do not imply a sequential progression. It is true that 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 steps 3.0 through 10.0 are done in parallel. This means that a project manager will be 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 not necessarily need to manage documentation (step 8.0) since a small project typically does not have enough documentation to get messed up. Likewise, the work required to manage 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 sized projects. A lively discussion can occur around the question of exactly when a project starts. Some say it starts whenever the idea surfaces for the work. Others say a project starts when the funding is approved. Another idea is to officially start the project when the Project Definition document is completed. For the purposes of this methodology, the project officially begins when a project manager is assigned. Typically the first job of the project manager is to formally define the work using a Project

Definition document, and build the workplan. This definition for the project start time still holds even if the formal project manager does not complete the Project Definition and workplan. Remember that project management is a role. Whoever completes the Project Definition 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 using this site. This website was created using Microsoft FrontPage. Therefore, the site can be viewed best using Internet Explorer. Although the site can be viewed with Netscape, it is not quite as clean and the formatting is not always consistent. The TenStep Project Management Process is designed to be applicable to all projects, whether you are building a house, a circuit board or a computer application. After all, all projects deal with planning, managing issues, scope, risk, etc. However, because the background of the author is in software development, you may see some particular reference or example that is software related (for instance, a suggested metric for system response time). In these cases, just substitute a comparable example that is applicable for your project (like circuit board speed). This methodology and website are designed to provide a large degree of value, while also being as concise as possible. After all, we want to avoid turning TenStep into one of those methodologies with thousands of pages that arent applicable to most projects. There is much more information that can be written for each of the steps in the process. For instance, there are entire books about the risk management process alone. Building a workplan is also the subject of many five-day classes. It is not the purpose of this website to provide an exhaustive and totally comprehensive amount of information on each step. TenStep recognizes that there are other project manager skills that are required to be successful on a project, including soft skills. A project manager should be a good verbal and written communicator, have good interpersonal skills, good listening skills, leadership skills, etc. The TenStep Project Management Process does not address these important types of personal 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 advice on people management.

This project management methodology is an umbrella under which the rest of the project work gets done. Remember that project management is the thing 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 includes analysis/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 this website. Some methodologies include the analysis work as part of the project management process. The TenStep Project Management Process includes enough high-level analysis so that the Project Definition document can be prepared. Otherwise, the formal analysis/business requirements phase is considered part of the project life cycle, and is out of the scope of the project management process. Similarly, some methodologies include work with vendors and contracts to be part of the project management process. The TenStep Project Management Process considers contract and vendor approvals, searches, evaluations, etc. to be a part of the project activities, not project management. In many organizations, this work is done by a separate Purchasing or Legal department. Although the project manager should be knowledgeable in this area, it is not considered a core project management skill in the TenStep process. Of course, vendors are going to introduce risks, issues, scope change, quality concerns, etc. So this project management process can still be used to manage these aspects of the relationship.

0.0.4 Process Overview


The TenStep Project Management Process is a scalable process based on the size of the project. All of the basic Ten Step processes provide guidance based on whether the project is small, medium or large. Each organization that utilizes Ten Step needs to determine what criteria it will use to classify projects. Ten Step uses three basic criteria for determining overall project size. The first is the estimated effort of the project. The general guidelines utilized by Ten Step are as follows: Size Small Medium Large Effort Hours 1-250 hours 251 - 5000 hours 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 you want in the project management process. The second factor is the experience level of the project manager. If the project manager is very experienced, then you might allow them to manage larger projects 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 as if it was a large one, since they may need more structure.

The third factor is the complexity and business criticality of the project. For example, 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 to manage a 500 hour project as a small one because you have managed two similar projects before and therefore it seems to be low risk. Next, start at Step 1.0 of the TenStep Project Management Process - Define the Project. Notice that there are various levels of detail needed for project definition, depending on the size of your project. Define your project based on the information described. It is a good practice to review all of the material for all three project sizes, because you may find other material that you want to incorporate into your particular project. Do the same for Step 2.0 - Build the Workplan, Step 3.0 - Manage the Workplan and Step 4 - Manage Issues. Start by understanding the recommendations for your sized project, and then add any activities from the other sized projects that will help your project. For the most part, all projects should follow the processes in Steps 1.0 through 4.0. Now on to Step 5.0 - Manage Scope. Everything you have read so far is still applicable, but there is an additional element regarding scope management. On larger projects, it is not only important to be more rigorous managing scope, but you must also do a more thorough job of defining scope. So, you will see new information added to the Step 1.0 - Define Project process. That is why you need to categorize your project into small, medium and large ahead of time. In some cases, the higher level project management processes also require more rigor in the early definition and planning processes. The rest of the TenStep Project Management Process works the same way. As described in the Assumptions Section, it is important to recognize that the ten steps of the TenStep methodology do not imply a sequential progression. It is true that 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 steps 3.0 through 10.0 are done in parallel. This means that a project manager will be 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 not necessarily need to manage documentation (step 8.0) since a small project typically does not have enough documentation to get messed up. Likewise, the work required to manage 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 sized projects. As always, review the content of each step for each project size. Then determine what activities make sense for your project. For instance, you may have a large project, but it may make sense to manage communication (Step 6.0) as if you were a medium project. You may have a large project, but you may not need to gather many metrics. In that case you could gather metrics (Step 10.0) as if you were a small project.

0.0.5 Home / Ten Step Principles


The following represent a set of guiding principles of the TenStep Project Management Process, and are reflected in all the subsequent content. 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.) The Ten Step Project Management Process is designed to be applicable to all projects, whether you are building a house, a circuit board or a computer application. The Ten Step process can also be applied regardless of the project life-cycle methodology used (Waterfall, Rapid Application Development (RAD), Agile, etc.) All projects have common needs to manage scope, risk, issues, quality, etc. Projects must be managed proactively, regardless of the size. Project managers that wait for things to happen most often get into trouble. A successful project normally requires a partnership between the project team and the client. The project is at higher risk of failure without active participation from the client.

1.

2.

3. 4.

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. 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.

6.

0.0.6 Ten Step Process Flow


As described in the Assumptions Section, it is important to recognize that the ten steps of the TenStep methodology do not imply a sequential progression. It is true that 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 steps 3.0 through 10.0 are done in parallel. This means that a project manager will be 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 not necessarily need to manage documentation (step 8.0) since a small project typically does not have enough documentation to get messed up. Likewise, the work required to manage 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 sized projects.

10

11

0.0.8 Comparison of Ten Step to the PMBOK


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 them in 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 Project Management Body of Knowledge (PMBOK), which is the standard put forward by the Project Management Institute (PMI). The PMBOK contains a lot of valuable information, and includes most all of the processes that TenStep contains. However, there is a difference in the packaging and emphasis. In the opinion of TenStep, Inc., the PMBOK provides a basic foundation for understanding how to manage work as a project, but is not necessarily a methodology that you can take to manage a project directly. For instance, there is information, but no procedures. There are definitions, but not necessarily best practices or techniques. 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 many readers 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

* This process mapping reflects the PMBOK 2000 edition.


Project Management Body of Knowledge (PMBOK) Ten Step Project Management Process

4. Project Integration Management 4.1 Project Plan Development 4.2 Project Plan Execution 1.0 Define The Work 2.0 Build the Workplan
This covers some aspects of Ten Step 3.0 through 10.0 as far as the overall management of the project. The activities in PMBOK 4.2 associated with the actual project work are not considered a part of the Ten Step Project Management Process. They are considered part of the project work itself.

4.3 Integrated Change Control

5.0 Manage Scope Change 8.0 Manage Documents 10.0 Manage Metrics

5. Project Scope Management 5.1 Initiation The PMBOK project approval process occurs before TenStep 1.0 Define the Work begins. The rest of the Initiation Process maps to 1.0 Define the Work. 1.0 Define the Work, specifically defining scope in the Project Definition. 2.0 Build the Workplan 1.0 Define the Work, specifically gaining approval of the Project Definition 5.0 Manage Scope

5.2 Scope Planning

5.3 Scope Definition 5.4 Scope Verification

5.5 Scope Change Control 6. Project Time Management 6.1 Activity Definition 6.2 Activity Sequencing 6.4 Schedule Development 6.5 Schedule Control

2.0 Build the Workplan 2.0 Build the Workplan 2.0 Build the Workplan 3.0 Manage the Workplan

6.3 Activity Duration Estimating 2.0 Build the Workplan

13

7. Project Cost Management 7.1 Resource Planning 7.2 Cost Estimating 7.3 Cost Budgeting 7.4 Cost Control 8. Project Quality Management 8.1 Quality Planning 8.2 Quality Assurance 8.3 Quality Control 9. Human Resources Management 9.1 Organizational Planning 1.0 Define the Work project level structure, within the context of organizational structure 2.0 Build the Workplan in regards to assigning project resources These soft-skills are not a part of the TenStep process, but are commented on widely in the Download Library for Licensed Users 1.0 Define the Work 9.0 Manage Quality 9.0 Manage Quality 9.0 Manage Quality 2.0 Build the Workplan 2.0 Build the Workplan 2.0 Build the Workplan 3.0 Manage the Workplan

9.2 Staff Acquisition 9.3 Team Development

10. Communications Planning 10.1 Communications Planning 10.2 Information Distribution 10.3 Performance Reporting 10.4 Administrative Closure 6.0 Manage Communication 6.0 Manage Communication 6.0 Manage Communication 3.0 Manage the Workplan Not a part of the base TenStep Process, but included in the 20.0 Related Topics. Project closure is considered part of the project related to project management, but not a core component.

11. Project Risk Management 11.1 Risk Planning


11.2 Risk Identification

1.0 Define the Work 7.0 Manage Risks


1.0 Define the Work 7.0 Define the Risks

14

11.3 Qualitative Risk Analysis


11.4 Quantitative Risk Analysis

1.0 Define the Work 7.0 Manage Risks 1.0 Define the Work 7.0 Manage Risks 1.0 Define the Work 7.0 Manage Risks 7.0 Manage Risks

11.5 Risk Response Planning 11.6 Risk Response Control 12. Project Procurement Management 12.1 12.2 12.3 12.4 12.5 12.6 Procurement Planning Solicitation Planning Solicitation Source Selection Contract Administration Contract Closeout

Procurement is not emphasized in TenStep because of the belief that this tends to be driven by a separate Procurement / Contracts Department. The project manager may execute parts of the process, but they do not own the process. There is some information in 20.0 Related Topics.
Other

Other

Issues management is not an emphasis of the PMBOK. Document management is mentioned as a part of 4.3 Overall Change Control, but is not emphasized

4.0 Manage Issues 8.0 Manage Documents

1.0 Define the Work


How many times have you heard about or been involved in a project that failed miserably? 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 Join the growing list of project managers receiving the Project said, "You know, we should have spent more time planning." Most projects have Management Tip of the Week. ** Sign-Up Now ** deadlines, and it seems they are getting shorter and shorter.

15

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 benefits include:

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 larger projects need a longer planning cycle. The effort required to plan the project depends on the amount of information, and the level of detail, that needs to be understood and documented. The duration required to define the work depends on the length of time necessary to discover and document the information, as well as the time required to gain agreement and approval from the client. At times, the project manager can get frustrated because of the difficulty in gaining agreement with the client on scope, timeline and cost. But that is exactly the reason this work 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 has started 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 be met 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 sought before project planning begins.

16

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 to staff 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 our understanding of what a project is. This will make it clearer when project management techniques are appropriate. For a general overview, see 1.0.1 What is a Project? When you have a sense for what a project is, you can also validate your understanding of the role of a project manager, at 1.0.2 The Role of a Project Manager. Now we can get on with the TenStep 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 / Process


All projects should spend time up-front in a definition step. For small projects, there is not much additional information needed, and therefore the planning process is short. As the project become bigger and bigger, the need to fully understand what is being requested is more important, and gaining agreement on what is to be delivered is harder to define. Therefore, more time needs to be spent planning the work. The following webpages describe processes for defining the work depending on the size of the project, 1.1.1 Small Projects - The Service Request Process 1.1.2 Medium Projects

17

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 call these enhancements or discretionary requests. For the purposes of the TenStep Project Management Process this work is considered to be a project because it meets all the criteria of the project definition. The work is unique, has a beginning and end date, results in the creation of a deliverable, etc. Its just that the work is small and so the project itself is small. In some organizations, small work efforts are considered a part of the support or operations organization. There are many work efforts that also fall under support because they originate with some type of problem or failure to a production process. 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. It can be hard to decide whether a small piece of work should be managed as a support request, or managed as a small project. The distinction used in TenStep is to look at whether there is discretion in when the work is completed. If a problem arises that requires a fix to be performed quickly, the work is definitely support. If a 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 short duration and small numbers of effort hours. Enhancements to existing production processes and systems. Bugs and errors in production processes that are nuisances, but can be scheduled for resolution at a later time. That is, fixing the problem is a lower business priority than other work. Small process improvements. Discovery or fact-finding work that may lead to further Service Requests or a project. Changes to production processes that are the result of legal, tax or auditing requirements. These requests may not be considered enhancements, 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

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. The result of this short definition is a one-to-two page document called a Service Request. Along with a much shorter project definition activity, the process for assigning the work is different as well. When the work definition for a larger project is completed, 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 any given time. Therefore, a process needs to be established for gathering Service Requests and assigning them to team members based on client priorities. Since there will likely be many Service Requests, it is important to have some way to keep track of them, and a way to ensure that the higher priority requests are being worked on. The following Service Request Process can be used.

1. Client submits the request. The client, with the help of the project
manager if necessary, completes a simple Service Request form that documents the work requested. Even though the work may be small, the Service Request serves as the formal document describing the work to be done, and contains the appropriate client approvals. A Service Request typically contains the work that is requested, the priority of the work and the business value of the work.

2. Project manager reviews and clarifies. The project manager reviews


the Service Request to ensure that the work is understood. The project manager asks questions of the client if necessary, to clarify what is being requested. 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 well enough, and if they have the proper level of expertise, they provide a high-level estimate of the effort hours and duration and include this information on the Service Request. It is possible that once the client sees the estimated effort, they may change their mind regarding the relative priority. For instance, if the effort is much higher than they realized, the priority may be lowered. If the estimate is much smaller than they realized, they may raise the priority higher so that the work can be completed sooner. If the project manager cannot estimate the work, they assign to a team member to create the estimates. If no one on the team has the time or expertise to create a high-level estimate, then the estimation process must itself be placed on the backlog. The client must decide if the effort required gathering information to create the estimate is of a high enough priority that they are willing to work on it rather than other Service Requests. This high-level estimate is used for prioritization purposes only. When the work is actually assigned, 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 on

19

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

5. Periodically review the backlogged work. The project manager and


client review the backlog on a regular basis. When the priority of a Service Request 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 critical than work that is in-progress, the previously assigned work is placed onhold, put back on the backlog, or used as filler while the new request is begun.

6. Revalidate the initial information. When the work is assigned to begin,


the person(s) doing the work should validate that the information on the Service Request is correct, and that the estimates are accurate. If they are not, then the new information should be documented and discussed immediately 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 not want to perform the work at that time. There may be other requests that are more critical and take less time to complete.

7. Manage the work. Once the work begins, it is managed through the
Manage the Work processes (Manage scope, communication, risk, etc.) Since the request is small, all of these project management processes are only utilized as needed. Project Management Procedures are not set up for individual small projects. Instead, generic procedures are established to govern 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 a closed queue that tracks these requests for historical purposes.

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 call these enhancements or discretionary requests. For the purposes of the TenStep Project Management Process this work is considered to be a project because it meets all the criteria of the project definition. The work is unique, has a beginning and end date, results in the creation of a deliverable, etc. Its just that the work is small and so the project itself is small. In some organizations, small work efforts are considered a part of the support or operations organization. There are many work efforts that also fall under support because they originate with some type of problem or failure to a production process. 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. It can be hard to decide whether a small piece of work should be managed as a support request, or managed as a small project. The distinction used in TenStep is

20

to look at whether there is discretion in when the work is completed. If a problem arises that requires a fix to be performed quickly, the work is definitely support. If a 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 short duration and small numbers of effort hours. Enhancements to existing production processes and systems. Bugs and errors in production processes that are nuisances, but can be scheduled for resolution at a later time. That is, fixing the problem is a lower business priority than other work. Small process improvements. Discovery or fact-finding work that may lead to further Service Requests or a project. Changes to production processes that are the result of legal, tax or auditing requirements. These requests may not be considered enhancements, 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. 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. The result of this short definition is a one-to-two page document called a Service Request. Along with a much shorter project definition activity, the process for assigning the work is different as well. When the work definition for a larger project is completed, 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 any given time. Therefore, a process needs to be established for gathering Service Requests and assigning them to team members based on client priorities. Since there will likely be many Service Requests, it is important to have some way to keep track of them, and a way to ensure that the higher priority requests are being worked on. The following Service Request Process can be used.

1. Client submits the request. The client, with the help of the project
manager if necessary, completes a simple Service Request form that documents the work requested. Even though the work may be small, the Service Request serves as the formal document describing the work to be done, and contains the appropriate client approvals. A Service Request

21

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

2. Project manager reviews and clarifies. The project manager reviews


the Service Request to ensure that the work is understood. The project manager asks questions of the client if necessary, to clarify what is being requested. 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 well enough, and if they have the proper level of expertise, they provide a high-level estimate of the effort hours and duration and include this information on the Service Request. It is possible that once the client sees the estimated effort, they may change their mind regarding the relative priority. For instance, if the effort is much higher than they realized, the priority may be lowered. If the estimate is much smaller than they realized, they may raise the priority higher so that the work can be completed sooner. If the project manager cannot estimate the work, they assign to a team member to create the estimates. If no one on the team has the time or expertise to create a high-level estimate, then the estimation process must itself be placed on the backlog. The client must decide if the effort required gathering information to create the estimate is of a high enough priority that they are willing to work on it rather than other Service Requests. This high-level estimate is used for prioritization purposes only. When the work is actually assigned, 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 on the backlog. They also review the available capacity and skills on the team to determine if the work can be started immediately. If the required resources are not available, or if the work is of lower priority than other Service Requests, the new request is placed on a backlog list. The backlog contains all work that has been requested, estimated and prioritized, but is not assigned to begin yet.

5. Periodically review the backlogged work. The project manager and


client review the backlog on a regular basis. When the priority of a Service Request 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 critical than work that is in-progress, the previously assigned work is placed onhold, put back on the backlog, or used as filler while the new request is begun.

6. Revalidate the initial information. When the work is assigned to begin,


the person(s) doing the work should validate that the information on the Service Request is correct, and that the estimates are accurate. If they are not, then the new information should be documented and discussed immediately 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 not want to perform the work at that time. There may be other requests that are more critical and take less time to complete.

22

7. Manage the work. Once the work begins, it is managed through the
Manage the Work processes (Manage scope, communication, risk, etc.) Since the request is small, all of these project management processes are only utilized as needed. Project Management Procedures are not set up for individual small projects. Instead, generic procedures are established to govern 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 a closed queue that tracks these requests for historical purposes.

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 call these enhancements or discretionary requests. For the purposes of the TenStep Project Management Process this work is considered to be a project because it meets all the criteria of the project definition. The work is unique, has a beginning and end date, results in the creation of a deliverable, etc. Its just that the work is small and so the project itself is small. In some organizations, small work efforts are considered a part of the support or operations organization. There are many work efforts that also fall under support because they originate with some type of problem or failure to a production process. 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. It can be hard to decide whether a small piece of work should be managed as a support request, or managed as a small project. The distinction used in TenStep is to look at whether there is discretion in when the work is completed. If a problem arises that requires a fix to be performed quickly, the work is definitely support. If a 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 short duration and small numbers of effort hours. Enhancements to existing production processes and systems. Bugs and errors in production processes that are nuisances, but can be scheduled for resolution at a later time. That is, fixing the problem is a lower business priority than other work. Small process improvements. Discovery or fact-finding work that may lead to further Service Requests or a project. Changes to production processes that are the result of legal, tax or auditing requirements. These requests may not be considered enhancements, since they do not provide any additional business value.

23

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. 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. The result of this short definition is a one-to-two page document called a Service Request. Along with a much shorter project definition activity, the process for assigning the work is different as well. When the work definition for a larger project is completed, 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 any given time. Therefore, a process needs to be established for gathering Service Requests and assigning them to team members based on client priorities. Since there will likely be many Service Requests, it is important to have some way to keep track of them, and a way to ensure that the higher priority requests are being worked on. The following Service Request Process can be used.

1. Client submits the request. The client, with the help of the project
manager if necessary, completes a simple Service Request form that documents the work requested. Even though the work may be small, the Service Request serves as the formal document describing the work to be done, and contains the appropriate client approvals. A Service Request typically contains the work that is requested, the priority of the work and the business value of the work.

2. Project manager reviews and clarifies. The project manager reviews


the Service Request to ensure that the work is understood. The project manager asks questions of the client if necessary, to clarify what is being requested. 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 well enough, and if they have the proper level of expertise, they provide a high-level estimate of the effort hours and duration and include this information on the Service Request. It is possible that once the client sees the estimated effort, they may change their mind regarding the relative priority. For instance, if the effort is much higher than they realized, the priority may be lowered. If the estimate is much smaller than they realized, they may raise the priority higher so that the work can be completed sooner. If the project manager cannot estimate the work, they assign to a team member to create the estimates. If no one

24

on the team has the time or expertise to create a high-level estimate, then the estimation process must itself be placed on the backlog. The client must decide if the effort required gathering information to create the estimate is of a high enough priority that they are willing to work on it rather than other Service Requests. This high-level estimate is used for prioritization purposes only. When the work is actually assigned, 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 on the backlog. They also review the available capacity and skills on the team to determine if the work can be started immediately. If the required resources are not available, or if the work is of lower priority than other Service Requests, the new request is placed on a backlog list. The backlog contains all work that has been requested, estimated and prioritized, but is not assigned to begin yet.

5. Periodically review the backlogged work. The project manager and


client review the backlog on a regular basis. When the priority of a Service Request 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 critical than work that is in-progress, the previously assigned work is placed onhold, put back on the backlog, or used as filler while the new request is begun.

6. Revalidate the initial information. When the work is assigned to begin,


the person(s) doing the work should validate that the information on the Service Request is correct, and that the estimates are accurate. If they are not, then the new information should be documented and discussed immediately 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 not want to perform the work at that time. There may be other requests that are more critical and take less time to complete.

7. Manage the work. Once the work begins, it is managed through the
Manage the Work processes (Manage scope, communication, risk, etc.) Since the request is small, all of these project management processes are only utilized as needed. Project Management Procedures are not set up for individual small projects. Instead, generic procedures are established to govern 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 a closed queue that tracks these requests for historical purposes.

1.2 Define the Work / Techniques


Work on the Project Definition and Project Workplan Simultaneously
There is not necessarily a sequential order between defining the project and building 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 the Project Definition, for instance, cannot be completed without starting to lay out

25

the overall project workplan. At the same time, you cannot complete the workplan without gaining agreement on the Project Definition. For instance, you cannot build the workplan without gaining a high-level agreement on deliverables and scope. 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 be done simultaneously. The two main deliverables, the Project Definition and project workplan, should also be developed in parallel. You will find that as you gather information around scope and deliverables, you can start laying out a high-level workplan. As you gather more information on the project, you can fill in more details on the workplan. When the deliverables, scope, assumptions and approach are complete, you should have enough information to be able to complete a highlevel workplan. You can then use the high-level workplan to estimate the necessary budget, effort and duration - which in turn are used to complete the Project 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. There are a number of problems with very large projects. The work is less clear the farther out in the future it is. Large projects are usually always long projects as well, and that makes them very difficult to plan successfully. Since the future work is less clear, it is harder to make accurate estimates for effort, duration and cost. Business and technical conditions change over time, making planning assumptions in the future very uncertain. The business and technical certainties of today can change dramatically over time. You risk losing organization support if there is a long delay before delivering tangible results. It is very difficult to maintain organizational enthusiasm and support over long periods of time. It is very difficult to predict resource requirements and availability far into the future. Again, this gets at the difficulty of estimating accurately as you get further out in the future.

In general, very large efforts are much too difficult and complex to manage as a single project. The better technique is to break the work down into more manageable chunks, each of which is considered its own project, with its own Project Definition and workplan. For instance, a long IT development effort can be broken into separate sequential projects 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 know then, to do the design work. Then a construct/test project is initiated, and finally a project for implementation. Other large initiatives might be broken up into smaller projects that might run in parallel. Some large initiatives can have a combination of smaller projects - some of which must be done sequentially, but others that can be done in parallel. Each team will work to complete its smaller project, but all the work 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 a need to maintain overall management and coordination. This is the purpose of setting 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-time project manager. The program is lead by a program manager. The program does

26

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 project teams. Determine how individual projects should be defined to ensure all the work gets completed successfully.

The Client May Not Know Enough to Completely Define the Project
Sometimes we place too high an expectation on the amount of foresight and vision that clients have. In many cases, the project manager will go to the client looking for answers to help define the project, and the client will not have all of the information needed. This happens all the time, and it does not mean that the client 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 yet articulate this into concrete deliverables. They may also not know all of the answers on scope, risks, project organization, etc. Based on having less than complete information, the project manager may feel the need to guess on the details. This is not a good solution. It is better to state up-front everything that you know, as well as everything that you do not know. If you are asked to come up with estimated effort, cost and duration, you will need to 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 a series of smaller projects (as described above). Even if the final results cannot be clearly defined, there should be some amount of work that is well defined, which will, 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 and plan 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 least know enough that you can plan the work for the first 90 days. Again, you plan the short-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 uncover more and more information, you can plan the remaining work at a more detailed level.

Project Organization - Roles and Responsibilities


For small projects, the organization is pretty simple - maybe just the project manager 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 formal organizational structure. You may have team members, an executive sponsor, a project 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 that everyone be clear on what their roles and responsibilities are. For example, the last thing you want is to have people give you direction as if they were the sponsor, when really they may just be management stakeholders. You also dont want people acting as team members, when really they are stakeholders. One aspect of defining the project is to define the organization structure and what the roles and responsibilities are. Usually the typical roles and responsibilities can be defined ahead of time for your organization, and then reused as appropriate

27

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

Project Approvals
Once the project has been defined, the project manager should seek formal approval from the appropriate sponsor and management stakeholders. There are many ways to gain formal project approval. Like most other activities in the TenStep Project Management Process, a little bit of planning is the key. For small projects, one signature from the main client or Project Sponsor is probably sufficient to show approval of the work to begin. This approval could also be via email confirmation. However, it should not be verbal. For larger projects, ask your manager and the Project Sponsor who should have explicit approval of the Project Definition, who should have implicit approval and who needs to get a copy for informational purposes only. In general, use the following approach as your starting point. Project Sponsor and key stakeholders. Get an explicit approval. This approval can be a formal signature on a paper copy of the Project Definition. It could also be an email specifically stating approval. You might also have some type of formal workflow approval. The key is that the approval is explicit and that you save a record of the approval. Other management stakeholders. Get an implicit approval. Implicit means that you assume they approve the Project Definition unless they get back to you otherwise. You would first send them a soft or hard copy of the Project Definition. Let them know you would like them to review the material and provide feedback if they are in agreement or if they have any concerns. Then give them a date for replying, and let them know that if you do not hear back from them before the date, you will assume they are granting their approval. If they come back to you with concerns, address them or take them to the Project Sponsor for resolution. Other interested parties. Send them a copy of the Project Definition. Let them know that it is for their information only. You should be available to discuss any content so that they can better understand the material, but you are not sending it to them for their approval.

28

1.3 Define the Work / Deliverables


Size Information Needed

Deliverable: Service Request.


(Note: This is probably a one to two page form. Nothing longer is needed.) Service Request Number (optional): This number ties the work to any other 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 as specific as possible regarding the new work or enhancements to existing system. Reason for Service Request (Optional): What is the benefit for doing this work? Assigned to: Typically include the specific people who will be assigned to Small the work. This may not be known up front, but can be filled in when the work 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 be reasonably close. Since there is not a lot of work, there should be few unknowns that would cause major estimating error. The project manager or a knowledgeable team member can complete the estimate. Estimated Duration: How long will it take to complete the work once it starts? Approval #1 / Date: Client signature to signify that the work on this request can proceed. (Ensures that the client is agreeing that the priority on this work is high enough that it can start.) Approval #2 / Date: (Optional) Client signature to signify agreement that the solution can be moved to production. Approval #3 / Date: Client signature to signify work has been successfully completed. ** Find Service Request in Template Library **

29

(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, see 2.1.1 Build Workplan / Process / Estimating. 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 Mediu as assumptions. Assumptions can be identified through the experience of knowing what m 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, see 7.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

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, see 1.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 to manage 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 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, see 2.1.1 Build Workplan / Process / Estimating. 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. 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 be identified as a risk. If so, then these should be identified as risks. For further information on

31

risks, see 7.1 Manage Risk / Process. Approach: At a high level, describe in words the information that is represented in the Project Workplan. This information is for the benefit of the client and stakeholders who will not be able to easily interpret the actual workplan. Describe major project phases and milestones, and the general sequence of the work. Communicate when the major deliverables will be produced. Explain any interesting techniques that the project will use, for instance Rapid Application Development (RAD), Joint Application Design (JAD) sessions, etc. Depending on the size of your project, this section could be fairly long. See 2.1.3 Build the Workplan / Approach for more ideas of how the approach can be described. Project Organization: The organization chart for a large project usually has more boxes that reflect more direct involvement from various stakeholders. For instance, the project may have a formal project manager from the client organization who also reports to the Project Sponsor. There may be a high-level Executive Sponsor, as well as a lower level Project Sponsor to represent the sponsor on a day-to-day basis. Key stakeholders may be organized into a Steering Committee to provide overall strategic guidance to the project. Vendors or suppliers may have a formal role and would need to be represented in the organizational structure. The three major ways that project teams are organized are described in 1.2.4 Define the Work / Project Organization. Large projects may also benefit from defining how deliverables get created and approved. This is described in further detail in 1.2.3 Define the Work / Responsibility Matrix. Many of the specific project roles are described in 1.2.2 Define the Work / Roles and Responsibilities. Approval Page: See Abbreviated Project Definition above. ** Find 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, Document Management, Quality Management and Metrics. (Starting points for these procedures can be found in subsequent steps of the TenStep Project Management Process.) ** Find Project Management Procedures in Template Library **

32

1.0.1 What is a Project?


Before you can be a good 'project manager' and apply good 'project management' techniques, you must first be sure that the work you are undertaking is, in fact, a project. Some people say that all work is a project. I don't think that is accurate. There are really two kinds of work - routine work (support) and project work. Routine work covers the normal things you do as an ongoing part of your job. In many organizations, this is called support work. For IT development people, support work consists of answering questions, going to regularly scheduled meetings, fixing problems in the production systems, etc. For sales people, this could be making daily sales calls, moving contracts through an approval process, updating call logs, etc. For an accounts receivable clerk this could be checking reports, balancing accounts, posting journal entries, closing out the system, etc. The key criteria is that the work is an ongoing, and routine, part of your job. This is the work you do today, tomorrow and a month from now. On the other hand, projects are not routine. The biggest difference is that projects, by their definition, have a defined start and end-date. There is a point in time when the work did not exist (before the project), when it does exist (the project), and when it does not exist again (after the project). This is the key determinant of whether a piece of work is a project. However, other characteristics of a project include a defined scope, finite budget, specific end result (or deliverables) and assigned resources. Another characteristic of a project is that the work is unique. Even if a project is similar to another one, it is not exactly the same because circumstances change and because things are always different when you are dealing with people. That being said, now you must get practical. In theory, projects can be one hour, 100 hours or 100,000 hours. So, you must recognize that, although the creation of a small deliverable is a project, it does not need the structure and discipline of a much larger project. For a one-hour project, you 'just do it'. Any planning analysis and design is all done in your head. For a twenty hour project, you mostly 'just do it'. However, now you may need to plan a little bit, maybe communicate a little bit, maybe deal with problems a little bit. A one hundred hour project probably has too much work to plan and manage it all in your head. For instance, you need to start defining the work and building a simple workplan. A five thousand-hour project needs full project management discipline. On the other extreme, a 10,000 hour project probably has too much to get our heads around it all. Now you start to break the larger project up into smaller, but related, projects to get the entire piece of work done.
Before proceeding through the TenStep Project Management Process, make sure you have a project and make sure you apply the appropriate discipline and rigor, based on the project size.

33

1.0.2 The Role of a Project Manager


A new employee in the company mailroom noticed an older man sitting in the corner, sorting mail, weighing packages, adding postage and doing other simple jobs. He asked his supervisor who the man was. "That's Joe." the supervisor said. "He has been with the company for 35 years and is getting close to retirement." "Really." the new employee replied. "And he's been in the mailroom the whole time?" "No, he left a number of years ago. But he asked for a transfer back - after spending several years as a project manager." On the surface, the role of a project manager should be easy to describe. In fact, from a textbook perspective it probably is. But the challenge to understanding roles and responsibilities is that they are different from company to company. So, although this webpage will provide an overall perspective of the role, you still need to determine what the role of a project manager is at your company, or in your organization.

General Definition
In general, the project manager is responsible for the overall success of the project. In some companies, this person might be called a Project Coordinator, or a Team Leader, however, the key aspect is that the person is responsible for ensuring the success of the project. What does it take for the project to be a success? If you follow the TenStep Project Management Process, or a similar approach, you first must define the project and build the workplan. This is where the project manager's responsibilities start. If the project begins and you find out later that you are not clear on scope, the project manager is the one who is accountable. If your project is executing a poor workplan, the project manager is accountable. The work around defining the project means that you understand and gain agreement on the overall objectives, scope, risk, approach, budget, etc. It also includes defining or adopting the specific project management procedures that will be used to manage the project. This does not mean that the project manager must do all this work themselves. There may be an entire team of people helping to create the Project Definition and workplan. However, if something does not go right, the project manager is accountable.

Process Responsibilities
Once the project starts, the project manager must successfully manage and control the work, including:

Identifying, tracking managing and resolving project issues Proactively disseminating project information to all stakeholders Identifying, managing and mitigating project risk Ensuring that the solution is of acceptable quality 34

Proactively managing scope to ensure that only what was agreed to is delivered, unless changes are approved through scope management Defining and collecting metrics to give a sense for how the project is progressing and whether the deliverables produced are acceptable Managing the overall workplan to ensure work is assigned and completed on time and within budget

Again, this does not mean that the project manager physically does all of this, but they must make sure it happens. If the project has problems, or scope creep, or faces risks, or is not setting expectations correctly, then the project manager is the person held accountable. To manage the project management processes, a person should be well organized, have great follow-up skills, be process oriented, be able to multi-task, have a logical thought process, be able to determine root causes, have good analytical ability, be a good estimator and budget manager, and have good selfdiscipline.

People Responsibilities
In addition to process skills, a project manager must have good people management skills. This includes:

Having the discipline and general management skills to make sure that people follow the standard processes and procedures Establishing leadership skills to get the team to willingly follow your direction. Leadership is about communicating a vision and getting the team to accept it and strive to get there with you. Setting reasonable, challenging and clear expectations for people, and holding them accountable for meeting the expectations. This includes providing good performance feedback to team members Team building skills so that the people work together well, and feel motivated to work hard for the sake of the project and their other team members. The larger your team and the longer the project, the more important it is to have good team-building skills. Proactive verbal and written communicator skills, including good, active listening skills.

Again, you are responsible for the success of the project. If the team has poor morale and is missing deadlines, you need to try to resolve it. If team members don't understand exactly what they need to do and when it is due, then you are responsible.

Multiple Roles Depending on the size and complexity of the project, the project manager may take on other responsibilities in addition to managing the work. For instance, the project manager may assist with gathering business requirements. Or they may help design a database management system or they may write some of the project documentation.

35

Project management is a particular role that a person fills, even if the person who is the project manager is working in other roles as well. For instance, a project manager might manage the project for 45% of their time, perform business analysis for 25%, work on design for 15% and write documentation for 15%. This does not mean that one of the responsibilities of a project manager role is to spend 15% of their time on design. Instead, it just means that the project is not large enough to need a full-time project manager. The project manager spends the rest of their time in other project roles such as Business Analyst, Designer and Technical Writer. Depending on the size of your projects and the way your company is organized, a project manager time may be allocated one of three ways.

They may have a full time role on a large project. They may have project management responsibilities for multiple projects, each of which is less than full time, but the combination of which adds up to a fulltime role. They may fill multiple roles, each of which requires a certain level of skill and responsibility. On one project, for instance, they may be both a project manager and an analyst.

Responsibilities in a Matrix Organization


The most prevalent organizational structure today is some form of matrix structure (See 1.2.4 Define Work / Project Organizations). The matrix organization allows the most efficient use of people resources for a company. However, one of the challenges of the matrix organization is that the team members are assigned to the project for work (full time or part time), but the resources report to someone else from a people management standpoint. This can mean that it is harder to get the resources to do the things you need to have done, and there is sometimes a sense that team members would rather do what their functional managers request, rather than what the project manager needs. In this type of a structure, there are still a number of proactive things you can do.

Although the team does not functionally report to the project manager, their work on the project should still be input into their overall performance review. So, you can try to hold people accountable by making sure they understand that you will be providing performance feedback into their review. This should also be reiterated, and agreed to, by the functional managers. If people are not meeting their deadlines, then perhaps it is a combination of your feedback, as well as the feedback from the functional manager that is needed. There are project management techniques and processes that should be utilized. First of all, if the availability and performance of the team is in doubt, you should raise this early as a project risk. As part of risk management, you need to put a proactive plan in place to make sure that this risk is addressed. When people miss their deadlines, you may need to raise an issue, and perform issues management. During issues management, you again look for the cause of the problem. Are they missing deadlines because they are being pulled from your project to do other work, such as application support? If so, this may need to be addressed one way. Are they missing dates because the

36

initial estimates were too low? If so, then that needs to be addressed another way. Are they missing dates because of performance problems? Again, that needs to be addressed a third way, with the help of the functional managers

In addition, make sure your team members are communicating proactively with you. In many cases, its not the fact that people miss their deadlines that gets the project manager frustrated. Its that they dont always give you warning. If a team member has a deliverable due at the end of the week, but they get pulled into a three-day resolution of a production problem, they need to let you know, so that you can take any appropriate actions. If they just miss their deadline, but do not tell you the reason or warn you ahead of time, then they are not managing expectations as they should. By the same token, you need to communicate proactively as well and make sure the team understands due dates and expectations. The project manager must also communicate proactively with the functional managers and make sure they know when there are resource-sharing issues or people performance issues.

Matrix management involves a complex and delicate balancing act between project managers and functional people managers. At the same time that you struggle to achieve your results from people that may not work for you full-time, you may also have additional non-project, functional responsibilities as well. The project manager always has limited people management authority in these situations. And yet it is possible to complete your projects successfully. There are many project management processes and techniques that can help. You should also make sure you utilize the project sponsor. After all, it is their project. They can help you generate the urgency and focus, and they can also have an impact on the functional managers, if necessary, to make sure that the project is successful. Having Project Management Accountability but not Responsibility In some organizations, the project manager is accountable for the success of the project, but does not have the right level of responsibility. Managing the team in a matrix organization is an example of that. You are asked to manage a project utilizing people that you do not have direct management responsibility for. In other cases, you may find that your ability to resolve issues is hampered because you are not high enough in the organization to get an issue resolved quickly. In other instances, you may find that your ability to be innovative and flexible is constrained by organizational policies and inertia. All of these cases can be cause for frustration. One way to deal with this is to define roles and responsibilities as a part of the Project Definition. This can help set and manage expectations. For instance, if you have no budget or expense approval authority, then note that up front, along with a process for expense approval. That way, if problems do arise later, everyone knows who has the right level of authority to resolve them. For most project managers, the frustration level is not caused so much by a lack of power as much as it is caused by ambiguity. If the project manager does not have the authority, it is important to know who does, and what process is needed to gain action.

37

S-ar putea să vă placă și