Hiển thị các bài đăng có nhãn Project management. Hiển thị tất cả bài đăng
Hiển thị các bài đăng có nhãn Project management. Hiển thị tất cả bài đăng
90.0 Close Project
90.0 Close Project
(90.0.P1)
Just as it is important to formally kick off a project, it is also important to successfully close the project. The value of having a planned project termination is in leveraging all of the information and experience gathered throughout the project. If the solution is implemented and the team immediately disbands, you don’t have an opportunity to wrap up the loose ends, perform staff evaluations, document key learnings or ensure that appropriate deliverables are transitioned to operations. Of course, a project can end unsuccessfully as well. Even in this case, there are still key learnings, team evaluations and other wrap-up activities to make the most of what was done on the project.
When the project schedule is created, think about the activities that need to be performed to gracefully and appropriately close the project. These activities include:
- Hold project conclusion meeting. A meeting should be held with the project team, sponsor and appropriate stakeholders to formally conclude the project. This meeting will include a recap of the project, documenting things that went right and things that went wrong, strengths and weaknesses of the project and project management processes, and the remaining steps required to terminate the project. Techniques or processes that worked especially well, or especially poorly, are identified as key learnings of the project. If your organization has a way to publish or leverage these key learnings, they should be sent to the appropriate group. (Key learnings that seem to work consistently on many projects, in many circumstances, might be raised to the level of a "best practice" and be utilized for all similar projects.)
An agenda for the conclusion meeting should focus on what the project was supposed to accomplish and what the project actually accomplished. The discussion should lead to a set of key learnings that describe what went well and what didn’t work. The agenda would be as follows:
- Declare success or failure. Sometimes it is obvious the project was completely successful and in other cases the project is a total failure. However, in many cases, there are mixed results. For instance, the major deliverables may have been completed, but the project was over budget. Or, the project team delivered on time and within budget, but the solution only met 80% of the business requirements. The key to declaring success is to define up-front what the success criteria are. If an agreement is reached with the sponsor and the appropriate functional manager on what success means, the project team can be evaluated against those criteria. The project team should first rate itself against those criteria, and then take the recommendation to the sponsor for validation.
- Transition the solution to operation (if applicable). If the solution will exist outside of the project, it should be transitioned to the appropriate operation organization. The transition includes knowledge transfer to the operation team, completion and turnover of all documentation, turnover of the list of remaining work, etc.
- Turn over project files (if applicable). A discussion should take place with the operation organization to determine which project and project management materials accumulated during the project should be turned over. Based on this agreement, some of the project material may be deleted or destroyed, backed-up, archived, etc. Those files and documents needed by the operation organization should be turned over to them to store in the appropriate long-term library or folders.
- Conduct performance reviews. If the project was substantial, it may be appropriate to do performance reviews after the project completes. In this case, the manager of the project manager and the project sponsor evaluate the project manager. The project manager reviews the entire team or at least the direct reports (and then the direct reports review their direct reports, until everyone is covered). Sometimes the team is rated as a whole and then team members use the team rating as input into a personal performance review. Other times, the team members may have individual reviews based on only their own contributions. There should be some link, however, between team and individual performance. It would not seem to make sense, for instance, that a project could fail and yet all of the team members receive reviews saying they all did an outstanding job.
- Reassign the remaining project team. Any remaining team members should be reassigned when all the termination activities are completed. For some people, this may mean completely new projects. For contract people, it may mean the end of their assignments. For part-timers, it may mean a return to their other full-time role.
It is the responsibility of the project manager to build project closure activities into the project schedule. These should be seen as vital parts of the project, not an afterthought as the team is getting disbanded. The project is not considered complete until the closure activities are performed
Close Contracts (90.0.P2)
Your project may have required the assistance of vendors for people, equipment, software, supplies, etc. Generally speaking, these project-specific contracts should be closed as a part of terminating the project. Of course, some contracts are broader than your project and these will remain open. You may have an open contract with a consulting firm, for instance, and you may have opened a Statement of Work for the specific services provided on your project. In that case, the general contract would remain open, but the specific Statement of Work would be closed. It is also very likely that all invoices have not been paid (or even submitted) when the project officially ends. However, the project manager or the appropriate contracts administrator should be responsible for closing these project-specific contracts after all outstanding bills have been paid.
Contract closure involves verifying that the work was competed and the updating of all contract records. Contract records are very important and include the contract itself and other relevant documentation such as progress reports, financial records, invoices, and payment records. These are often kept in a contract file, which should be part of the complete project file. Contract documentation is also important should a procurement audit be initiated. Such an audit is a structured review of the procurement process from planning through contract.
10.0 Manage Procurement
10.0 Manage Procurement
Overview (10.0.P1)
Procurement refers to obtaining goods and services from outside companies. This specifically refers 
to vendors and suppliers. (For the purposes of this discussion, purchasing and procurement are equivalent terms.) This is an area that project managers definitely need to understand at some level, and it is an area into which the project manager will give input. However, in many, and perhaps most companies, procurement is an area that the
to vendors and suppliers. (For the purposes of this discussion, purchasing and procurement are equivalent terms.) This is an area that project managers definitely need to understand at some level, and it is an area into which the project manager will give input. However, in many, and perhaps most companies, procurement is an area that the
project manager does not own. The project manager may not have the authority to enter into contracts on behalf of the company, and he normally is not asked to administer the contracts once they are in place.
If you are purchasing goods or services on your project, you should determine your project procurement strategy and plans. In some cases, you will simply follow the procurement contracts and plans that are already established by your company or your organization. For instance, you may purchase hardware from companies using a standard company contract. You may acquire contactors using your company’s preferred vendor list under prior master contractor agreements. In some cases, you will need to work with your Procurement Department to establish your own project-level vendor management plans.
9.0 Manage Quality and Metrics
9.0 Manage Quality and Metrics
(9.0.P1)
Quality is ultimately defined by the customer and represents how close the project and deliverables come to meeting the customer’s requirements and expectations.
The old adage about quality being in the eyes of the beholder is true - quality is ultimately measured by your customer. It is not up to the project team to determine the level of quality required for the project. The project team needs to understand the customer's requirements and expectations - and then meet those expectations.
High-level process flow
|
This is a critical concept about quality. Sometimes there is a tendency to think that 'quality' means the best material, the best equipment and absolutely zero defects. However, in most cases, the sponsor does not expect, and cannot afford, a perfect solution. If there are a few bumps in the project or a few defects in the deliverable, the customer can still say that the solution was delivered with a high level of quality. On the other hand, a flawlessly designed, defect-free solution that does not meet the customer's needs is not considered high quality. The purpose of quality management is to first understand the expectations of the customer in terms of quality and then put a proactive plan in place to meet those expectations.
Since quality is defined by the customer, it may seem that it is completely subjective. However, there is a lot about quality that can be made objective. This requires first breaking down the generic term of 'quality' into the specific aspects of quality that are important to the customer. Then, you look at each of the individual aspects and determine one or more metrics that can be collected to measure the characteristic. For instance, one of the features of a quality solution may be that it has a minimum amount of errors. This characteristic can be measured by counting errors and defects after the solution goes live.
In addition to understanding the customer’s definition of quality, it is important to recognize other stakeholder’s interests as well. Depending on the roles of the stakeholders, they may have other quality requirements that need to be satisfied. For instance:
- The company – The solution meets strategic goals
- Buyers - The solution meets specifications
- End users – The solution helps them do their job better, faster, easier
- IT support organization – The solution is stable, has few bugs, is understandable and can be modified easily
Managing metrics and managing quality are related. It is very difficult to improve the quality of your deliverables or your efficiency of your processes if you are not gathering metrics. Metrics are used to give some indication of the beginning state of quality (quality of deliverables and quality of project processes) and whether quality is increasing or decreasing. In addition to determining the level of quality on a project, metrics can also be used to provide objective criteria to determine if your project was successful. This is the purpose of the project scorecard.
8.0 Manage Human Resources
8.0 Manage Human Resources
(8.0.P1)
A project manager is 100% responsible for the processes used to manage a project. The project manager also has people management responsibilities, although these responsibilities are shared with the functional managers of the team members.
Some people go as far as to say that managing people on a project is the most challenging and the most important of all the project management responsibilities. Managers that can manage processes but are not very good with people may still be successful on their project. Project managers that are not good at managing processes but are good at managing people may also experience success, although probably at a lesser degree than the prior case. The best project managers do a good job managing the project management processes, plus do a good job acquiring, developing and managing the project team.
High-level process flow
|
7.0 Manage Risk
7.0 Manage Risk
(7.0.P1)
Risk refers to future conditions or circumstances that exist outside of the control of the project team that will have an adverse impact on the project if they occur. Whereas an issue is a current problem that must be dealt with, a risk is a potential future problem that has not yet occurred.
A reactive project manager addresses issues when they occur. A proactive project manager addresses potential problems before they occur. This is the art of risk management.
High-level process flow
|
All projects have some degree of risk. Projects with a higher level of risk require more rigorous risk management. Although not all risks can be eliminated entirely, most can be anticipated and managed ahead of time.
The purpose of risk management is to identify the risk events for a project and then establish a Risk Management Plan to manage the risk event and minimize harm to the project. In the TenStep process, the initial risk management during the 1.0 Define the Work step. Additional risk identification should occur throughout the project.
6.0 Manage Communication
6.0 Manage Communication
(6.0.P1)
Properly communicating on a project is a critical success factor for managing the expectations of the sponsor and the stakeholders. If these people are not kept well informed of the project progress there is a much greater chance that you will face problems due to differing expectations and surprises. In fact, in many cases where conflicts arise, it is not because of an actual problem, but because the person was surprised.
All projects should communicate status. This includes reporting from the project team to the project manager and reporting from the project manager to the sponsor and stakeholders. Two typical forums for communicating status are through a status meeting and Status Reports. Larger projects or any project that requires culture change need to be more sophisticated in how they communicate to various stakeholders. This more multi-faceted approach is defined in a Communications Plan.
High-level process flow
|
5.0 Manage Scope
5.0 Manage Scope
(5.0.P1)
It is said that the only constant in the world is “change”. You can make perfect plans, but they cannot account for every potential change that may occur. The longer your project, the more likely you will be dealing with changes. This is one reason why the TenStep process recognizes that the initial definition (step 1) and planning (step 2) processes do not have to be perfect. You and your team need to do the best job you can with what you know at the time. That is good enough. After that you need to manage the changes.
High-level process flow
Scope Change (5.0.P2)
Scope is the term used to describe the totality of the work and the overall boundaries of the project. Scope is used to define what the project will deliver and what it will not deliver.
If you look at the reasons that projects fail, it is usually the result of two problems.
- Lack of planning to sufficiently understand the nature of the project.
- A lack of scope change management. Even if the project manager did a good job of defining scope, the hard part comes in having to manage the project within that agreed-upon scope.
The purpose of scope change management is to protect the viability of the approved Project Charter and the approved business requirements. In other words, the Project Charter defines the overall scope of the project, and the business requirements define the deliverables in detail. The project team committed to a deadline and budget based on this high-level and detailed scope. If the deliverables change during the project (and usually this means that the sponsor wants additional items), the estimates for cost, effort and duration may no longer be valid. If the sponsor agrees to include the new work into the project scope, the project manager has the right to expect that the current budget and deadline will be modified (usually increased) to reflect this additional work. This new estimated cost, effort and duration now become the approved target.
Sometimes the project manager thinks that scope management means having to tell the sponsor ‘no’. That makes the project manager nervous and uncomfortable.
However, the good news is that managing scope is all about getting the sponsor to make the decisions that will result in changes to project scope.
This is very important. Few customers can see and express every requirement up-front. Therefore, there are usually changes that need to be introduced during the project. These changes may be very necessary for the solution and there may be valid business reasons why they should be included. The project manager and project team must recognize when these changes are requested. Then they must follow a predefined scope change process. This process ultimately brings the appropriate information to the project sponsor and allows the sponsor to decide if the modification should be approved based on the business value and the impact to the project in terms of cost and schedule.
4.0 Manage Issues
4.0 Manage Issues
(4.0.P1)
Issues are more than just common problems. They are problems that meet specific criteria. An issue is a formally-defined problem that will impede the progress of the project and cannot be totally resolved by the project manager and project team without outside help. Let’s look at that definition again.
- A formally defined problem. You must be able to document a problem if you hope to resolve it. While the problem is formless and vague it cannot be solved. In addition, you need to be able to communicate the nature of issues, and this requires that they be documented as well.
- Impede the progress of the project. There are many problems that that do not have an impact on your project. Likewise there are also problems that arise on your project that are not significant enough to impact your progress. Issues do have an impact on the project. They must be resolved since they are impeding the progress of your project.
- Cannot be totally resolved without outside help. This is also a key point. If the project team can resolve a problem it does not rise to the level of an issue. An issue cannot be totally resolved by the project team. The project team may have some influence on resolving an issue, but the resolution is not totally in their control.
High-level process flow
|
Many projects have to resolve issues. They cannot be ignored and they cannot be deferred to some later time. Issues must be resolved quickly and effectively.
3.0 Manage the Schedule and Budget
3.0 Manage the Schedule and Budget
(3.0.P1)
You have now defined the work (Project Charter, Project Management Plan) in Step 1and planned how you will complete the work (project schedule, budget) in Step 2. Now you must manage the schedule and budget to ensure that the project finishes within your deadline date and within budget.
High-level process flow for managing the schedule
|
The schedule should represent your best-guess at any particular point in time on how to complete the remaining work. The more complex your project is, the more change is going to be required in your “best guess” over time. That is why managing the project schedule is such an important project management skill. The project manager must evaluate the schedule on an ongoing basis and determine the current state of the project against the baseline schedule. Based on the current state of the project, and your current understanding of the work remaining, you need to re-plot a course that will allow the work to be completed within the original budget and deadline.
High-level process flow for managing the budget
|
For most projects, the schedule will need to be reviewed on a weekly basis. During this review, the project manager updates the schedule with the current state of work that is completed and in-progress. The remaining work should be evaluated to see if the project will be completed within the original effort, cost, and duration estimates. If it can, you are in good shape. If it cannot, the project manager must implement corrective action.
Of all of the skills required for managing the project, managing the schedule is perhaps the most fundamental. Depending on the dynamics of your project, the project manager may be in a position of having to constantly utilize his experience and creativity to get the project completed within expectations. One week your project may be on track. The next week, you may have work assignments that are late and issues that have surfaced. If an activity on the critical path is a week late, the project manager cannot sit back idly and allow the entire project to be a week late. Instead, he must evaluate the resources and options available and get the project back on track. If you are good at it, managing the schedule can be one of the more challenging and rewarding aspects of project management. If you do not relish the detailed work that is required, you may find it much more difficult to be successful as a project manager.
Kicking Off and Closing the Project (3.0.P2)
After the project is defined and planned, the actual execution of the project can begin and the project deliverables can be created. This work is also called the project life cycle. The project life cycle is surrounded by two events – a project kickoff meeting to officially start the project execution and a set of project closure activities to officially end the project. For more details see 3.1A.3.1 Project Kickoff 
and 90.0 Close Project)
and 90.0 Close Project)
Integrating the Project Lifecycle and Project Management Processes (3.0.P3)
The schedule is the focal point of managing the project, and all the project management processes are integrated in the schedule. You should have activities and time allocated in your schedule for communicating, managing scope, updating the schedule and all other project management activities. The integration occurs when the project management processes touch each other, as well as when the project management and project life cycle activities overlap.
2.0 Build the Schedule and Budget
2.0 Build the Schedule and Budget
(2.0.P1)
The project schedule and budget is created along with the Project Charter from Step 1.0. The schedule is a vital tool to ensure that the project team knows what they need to do.
The budget represents the amount of money available to spend on the project. Depending on your organization and how you do your accounting, the budget could contain only the external costs of the project (contractors, hardware, software, material, etc.). Some organizations also include the costs of internal labor in the budget. These organizations typically have some type of chargeback process to allocate the internal costs back to the sponsor or sponsor department.
The Define the Work step ensures you have an agreement with the project sponsor on the work that should be completed. In this step the project manager determines how the work will be completed. Depending on the size of the project, it is possible to use a project management package like MS Project, a spreadsheet or you could even just keep track of the activities in your head.
The Relationship Between the Schedule and Budget (2.0.P2)
The TenStep Project Management Process has always tied the schedule and budget into a single integrated component. Of course the two concepts are different. The schedule shows the activities required to build the deliverables of the project. The budget shows how much money the project will require.
The TenStep process realizes that these are two fundamental processes are key to the project success, and in many organizations represent the two fundamental components of project success – did we meet expectations for schedule and budget? The two elements of project management are usually linked.
- If a project is behind its schedule it is generally over budget as well.
- If a project is over budget it is usually trending over its deadline as well. (Of course there are exceptions, but the two elements usually have a common trend.)
- If you have underestimated the amount of work, you are generally going to have underestimated both the schedule and the budget element.
- The effort hours applied from human resources on the project are going to impact both the schedule and the budget.
- They are two integrated elements of the overall triple constraint, which links the schedule, budget and project scope. If the scope of the project is increased (or decreased), the schedule and budget elements need to increase (or decrease) as well.
Project manager experience usually shows that the schedule and budget elements of the project are closely tied.
The Relationship Between Defining and Planning the Work (2.0.P3)
Defining the work is step 1 of the TenStep process and creating the schedule and budget is step 2. However, this numbering does not imply that these are sequential. You will usually find that you cannot complete the Project Charter without starting to lay out the overall project schedule. In many cases, these two deliverables need to be worked on in parallel. As you gather information around scope and deliverables, you will need to start laying out an overall timeline and budget so that you can get your hands around estimated effort and duration. As you get more “definition” information, you will fill in more detail on the schedule. When the deliverables, scope, assumptions and approach are complete, you should have enough information in the schedule to estimate the necessary budget, effort and duration - which in turn are used to complete the Project Charter.
1. Define the work
1.0 Define the Work
(1.0.P1)
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? If you did, chances are that you will have said, "You know, we should have spent more time planning."
Most projects have deadlines, and it seems they are getting shorter and shorter. Hitting aggressive deadlines puts pressure on the project manager to start the project as soon as possible. However, before the project work begins, you need to spend time 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 sponsor 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.
High-level process flow
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, these benefits include:
- Understanding and gaining agreement on project objectives, deliverables, scope, risk, cost, approach, etc. This ensures that the project team and sponsor agree on the work that is required.
- Determining if the original business case is still valid. When the project was initially approved, the project cost and duration were probably estimated at a high-level – maybe up to ± 50%. Now that the project is starting, the estimates should be revalidated to get them closer to ± 15%. This additional refinement may result in the estimates ending up higher than before, and these higher numbers may make the business case unattractive. 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 anymore.
- Making sure the resources you need are available when you need them. This is a result of creating the project schedule with resources assigned.
- Providing a high-level baseline from which progress can be compared. This is a result of creating the milestone timeline based on the more detailed schedule.
- Validating the processes used to manage the project ahead of time with the sponsor. The procedures that are used to manage the project should not be a surprise. They should be discussed and agreed to ahead of time.
It should make sense that small projects need a shorter planning cycle and larger projects need a longer planning cycle. The effort required to define the work depends on the amount of information and the level of detail that need 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 sponsor.
At times, the project manager can get frustrated because of the difficulty in gaining agreement with the sponsor on scope, schedule 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 sponsor on scope, schedule or cost when the work has started and the deliverables are actually being produced.
Understanding Projects (1.0.P2)
Before you learn how to define the work, you should be clear on the definition of a project itself. This will make it clearer as to when formal project management techniques are appropriate.
The processes used to manage your project need to be scalable based on the size of the project. Large projects need to be managed with more rigor and structure than small projects.
Sizing the Project (Small, Medium, Large) (1.0.P3)
The processes used to manage your project need to be scalable based on the size of the project. Large projects need to be managed with more rigor and structure than small projects.
The TenStep process contains specific guidance for how to manage a project based on the size. But first, you have to categorize your project as large, medium or small. In some companies a project of six months and 10,000 hours would be considered large. In other organizations, this same project would be considered small. The TenStep process includes some guidelines, but each organization should determine the guidelines that make sense for them. See 1.0.3 Sizing your Project (Small, Medium, Large) for more information.
After you have reviewed the prior information, proceed through the information on defining your project.
Đăng ký:
Bài đăng (Atom)