Archive for year: 2014

There is concern from many project managers that they are expected to estimate the effort, duration and cost of a project at the end of the planning process before the detailed requirements have been gathered. It seems like a valid question. Yet, when you talk about gathering detailed requirements, you are usually talking about the Analysis (or Specification) Phase of a project lifecycle, not the up-front planning process.

Of course, you need to have a high-level understanding of the requirements before you can provide project estimates. However, the details are gathered after planning.

The following three approaches will allow you to execute the project before you have gathered the detailed business requirements. (As with many aspects of project management, iterative and Agile requirements are gathered differently.)

• Estimate the work to within 15% after planning. This is the traditional approach. Many projects are estimated this way because the project is not so different from projects you have done before. If you have experience with similar projects you can make a reasonable estimate based on the characteristics of the project.
• Break the work down into smaller pieces. If you don’t feel comfortable to provide an overall project estimate within 15%, you can break the larger project into multiple smaller projects. When you use this technique, you usually end up chartering an initial project to gather the requirements. You should be able to estimate this requirements gathering project to within 15%. After this requirements project is complete, you can use the information to charter a second project to perform the rest of the work, also within 15%.
• Estimate in two parts. This is a variation on the first technique above. In this approach, the project manager provides a “best guess” estimate of the work at the end of planning. This estimate may be within 25% (or higher). However the project manager is not accountable for this estimate (unlike the first option above). This estimate is just best-guess given the information at the time. After the requirements are completed, the project manager provides a more detailed estimate of the work within 10-15%. This is the number for which the project manager is held accountable. Unlike the second approach, these two estimates are both made within a single project.

The first estimating approach is within the control of the project manager. The second and third approach likely require approval of your sponsor and manager. But either approach is better than taking a guess and having to live with the consequences of a bad estimate. That is not good for the project team or the organization.

Do you need help with estimating skills or estimating processes? Contact Menno Valkenburg or Dick van Schoonhoven for more information and to discuss your specific needs.

Every time you’re given a new project, you first start with a process of initiating and planning. There are additional things to consider to ensure you start the project off right.

1. Take responsibility. Take responsibility for delivering the project, and ensure other stakeholders are accepting their responsibilities as well. Be sure the sponsor will provide strong sponsorship, and that you have adequate funding and resources to complete it on time. Be sure you have a gut feel that the project is achievable. If you have concerns about the viability of the project raise your concern. Taking responsibility does not mean to be an order-taker. It means you also take responsibility to push back when needed.
2. Understand the background and context. You really need to understand as much as possible about your customer’s business to know why the scope and priorities have been set as they have. Ask your customer what’s driving the deadline of anything, why you can’t reduce the scope further and why the deliverables have been prioritized as they have. This gives you good information to start the planning process.
3. Identify the stakeholders. This is one of the most important aspects of starting a project. You need to know who the players are and their roles and responsibilities. You will need this information to know who to talk to for planning the project.
4. Clarify the scope. You need to uncover the scope of the project to ensure that all of the deliverables to be produced during the project are adequately defined. You don’t want to get part way through the project only to find that your customer actually wanted different or additional deliverables that weren’t planned. Sit down with your customer and clarify all of the deliverables on day one. The complete set of deliverables forms the “scope” of the project and it’s critical that you document these before you get started.
5. Understand if there is a fixed deadline and budget. Many projects have their deadline and budget set depending on the scope of work and the resources available. On the other hand, some projects are assigned to the project manager with a fixed deadline and budget. These projects can be harder to deliver. When a project starts it is important to know if you can propose the budget and deadline based on the work, or if these will be constraints given to you ahead of time.

…

Many teams struggle understanding how best to initiate and plan a project. Invite us in to help. We can facilitate a Project Quickstart session that helps identify project objectives, scope, risks, assumptions, constraints, milestones and more. Please call Menno Valkenburg +31(0)649417755 or Dick van Schoonhoven +31(0)611045033.

Risks are future events or conditions that have some probability of occurring and some impact to your project. You usually always think of risks as being bad.

However, is it true that all risks are bad? Let’s say your project was going to utilize a new tool or new technology. This introduces some risk since you have not used the tool before.

If it is true that projects are generally more risky when you use new technology, why would you ever undertake a project with new technology? The answer is that you perceive there to be a benefit to your project. In other words, the potential impact to your project is a positive. This still meets the definition of risk.

• There is an impact to your project. Normally risk events have a negative impact on your project. However, with positive risk there is a potential positive impact.
• There is a probability of the event occurring. This is still the case with positive risks. In the prior example, if the benefits of moving to new technology were guaranteed, you could make the decision to move forward with 100% confidence. However, the implementation of the technology could turn out bad, in which case you might be worse off than when you started.

Positive risk is also called “opportunity risk”. In these instances, the project manager or project team may introduce risk to try to gain much more value later.

One of the key aspects of positive risk is that you put yourself in a position to take on the risks. Negative risks are potential events that can happen to you. They are the ones that you want to avoid or eliminate. Positive risks are those that you knowingly take upon yourself. They are not out there ready to get us. They are the risks that you step up to since you perceive there to be advantages to do so.

Generally when you are doing risk management on projects you are talking about potential negative events. However, you can also identify the risk events that lead to positive outcomes. These opportunity risks can be managed the same way as negative risks except that instead of eliminating the risks, your risk plan will include activities designed to give you the best chance that the risk event will come true.

Does your team need additional training and coaching on how to manage risks? Please contact us.

[image source_type=”attachment_id” source_value=”150″ align=”right” width=”300″ autoHeight=”true”] There are many companies that do not have common project management processes, templates, approach and skills. One initial observation is that companies that don’t manage projects well are usually run by senior managers who never learned formal project management themselves. It is hard for them to lead culture change around project management when they don’t understand the value themselves. In fact, sometimes these managers think of project management as a tool for managing projects, rather than as a process for doing the work. When they discover a tool isn’t involved, they lose interest.

There are a number of other reasons why companies have not implemented project management processes. These include:

• The company does not have committed sponsorship.

Some managers want to hold a training class and hope that project management sticks. They don’t have a strong commitment to the culture change required to get better at managing projects. In large companies, it could take two to three years, or longer. The sponsor needs to be committed and focused long term to make the changes successfully.

• The entire organization is not included.

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 Charter document, and your sponsor asks why you were wasting your time, you are probably not going to be very excited about the planning process on your next project. To be effective, the entire organization must be part of the project management initiative.

• The organization does not have a lot of pain around projects.

This is very common, especially in small to medium sized organizations. In many companies, the projects are not under pressure to complete within fixed deadlines and budgets. They just need to be completed within a “reasonable” timeframe. In these companies, there is not much internal pressure to change the status quo.

• The organization is not scaling the processes and approach.

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 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 Charter even if your project is only 200 hours, you may have been turned off. This is not usually a methodology problem as much as it is a misapplication of the methodology.

• The project teams fight the changes.

Many people want to solve problems and do their jobs creatively, with a minimum of supervision. They fear that project management techniques will result in controls that will take the fun out of the work. Without strong sponsorship, the project teams resist the change until the pressure goes away.

• 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 people to coordinate the projects, but then they want to make all the decisions and exercise all the control. Formal project management will not be possible in organizations where this fear is prevalent.

Summary

These are some common reasons why project management is not sponsored at companies, and when it is sponsored, why it does not always stick. However, almost every study that looks at project management shows that it is a discipline that will help project managers deliver on time, on budget and within client expectations. All companies should have a common project management process to maximize the chances for delivering their projects successfully.