Reasons for a Quality Management Process

/in /by

The reasons for a quality management process to be documented for your next business venture will help to set your credibility level amongst your customers. This document is where the specifications are laid out, in detail, for your customers to know just what to expect when they receive your deliverable. It is also the place your quality assurance team will be able to locate the information they need.

The quality management process specifically puts into writing just what level of quality your deliverable will be at. The specifications in these documents will be in a range. This will allow your target audience to be aware of just what they will be receiving when they purchase your product for use by their organization. This is necessary since with an increase in quality generally comes an increase in price. Most organizations look for the lowest cost products that will meet their needs or specification.

The quality management process will also have the information that is necessary for your quality assurance team to create the necessary methods and procedures so you’re deliverable can be inspected to make sure it attains the goals of the documents. When the quality control department records the findings from inspecting the deliverable, you will have the proof necessary to prove to your target audience you are producing what you claim to be making.

This proof is how the quality management process will help you to attain the requirements now necessary that are set by the internationally accepted standards for the global market place. By having this record readily available when entering a new region of the world, the red tape and delays to this new market place will be reduced. This makes it easier and faster to begin the selling of your product so a new revenue stream can be developed.

By having a quality management process documented and in place, your organization will become more efficient in creating new and profitable revenue streams. With this proof, you can show any possible regulator or inspector that you are in compliance with the standards they require.

Yes, You Need to Estimate the Project Size Before Gathering Detailed Requirements

/in /by

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.

You Need to Collect Metrics. Here are Two Approaches.

/in /by

There are two approaches for organizations looking to start collecting metrics. One is a formal, structured approach and one is an unstructured “let’s just do it” approach.

The Structured Approach
One way to get a metrics program started is to get a set of key stakeholders together and go through a planning exercise. This takes some discipline and forward thinking. The overall steps would include:

  • Identify criteria for success. First you need to define what success means to your organization. You would normally look at your business plan, strategy, vision, departmental objectives, etc.
  • Assign potential metrics. Identify potential metrics for each of your criteria that provide an indication of whether you are achieving success. This is a brainstorming exercise so that you identify as many potential metrics as possible.
  • Look for a balance. The potential list of metrics should be placed into categories to make sure that they provide a balanced view of the organization. For instance, look for metrics that provide information in the areas such as cost, project success, quality, productivity, client satisfaction, business value, safety, etc.
  • Prioritize the balanced list of metrics. Depending on how many metrics you have identified, prioritize the list to include only those that have the least cost to collect and provide the most value to the organization. You usually want to end up with 5-8 metrics.
  • Set targets. The raw metric may be of some interest, but the measure of success comes from comparing your actual results against a predefined target.
  • Collect and analyze the information. Now the hard part – set up the processes to collect the metrics and analyze them on an ongoing basis.

The Unstructured Approach
There is another approach that can work. The basic philosophy is “just collect something, even if it’s wrong.” In this approach, some key people in the organization get together and look for information that can be easily captured that provide some indication of success in some areas. Then you start to collect and analyze. After you collect the data over time, you get a sense for whether the metrics are providing value and whether you need to find more or different ones. This approach gets you into the habit of collecting and analyzing metrics first and allows you to improve your metrics over time.
Summary

Deciding to start collecting metrics is a great first step, but now you must decide how to get started on the work. Many organizations like a deliberate and thoughtful process to determine the metrics program. This can help you be more successful the first time.
The problem is that sometimes you don’t get past the planning to actually collect and analyze the data. Many organizations are not sure what information they need, so they just start to collect and analyze what is available. They then improve the collection and analysis over time. For many organizations it is better to develop good habits than to try to get things perfect the first time.

Let 2015 Be the Year for Getting Serious About Metrics
Yes, We know. Metrics are hard. Every organization knows they need to get better at collecting and analyzing performance data. But few do a good job. Yes, it is hard work.
At TenStep, we have a great model for setting up a metrics program. We can help you collect and analyze the right set of metrics at the project, program, portfolio orr organization level.
Contact Menno Valkenburg or Dick van Schoonhoven for more information and to discuss your specific needs.

Change Management Theory

/in /by

The change management theory that is the most effective is the one that can implemented the change successfully without any disruption in to the daily work routine of the staff. Unfortunately this does not occur to often. To help increase the odds of implanting the change in the most effective manner, the creation of a change management plan is needed.

The creation of such a plan has to take into account the change management theory of little disruption. This will then require that the project manager who is creating the plan to know their staff. The information needed is their ability to learn, follow orders and their ability to accept change. This knowledge will help set the path to which is the best way to introduce the changes and how to introduce them.

The change management theory is usually a generic model that looks great on paper. This does not always mean it is practical to follow precisely within all organization. Adjustments need to be made for the staff and their real life expectations on accepting the change.

Change is not something that is general welcomed. Most workers get set into a groove or routine and do not want is disturbed. The average change management theory does not take this into account. This is the responsibility of the project manager to make the two meld together so the implementation can occur seamlessly. While this is difficult, it is possible.

What the project manager has to include from the change management theory into their change of management plan is the goals and scope of the change. These have to remain unchanged so the final results will be achieved as wanted by the upper management. This is where the disruption usually takes place even if the change is for the good of the staff that have to use it.

The change management theory is a great thing to have on paper, but can rarely be followed precisely. The staff are living beings with feelings and emotions along with different learning capabilities. All of them must be taken into account when formulation your change management plan.

Consider These Five Steps When Starting a Project

/in /by

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.

Agile 101 – Estimating Work with Story Points

/in /by

In each iteration Agile project teams implement a set of user stories pulled from the Product Backlog in priority order. The number of stories implemented in each iteration depends on the amount of effort it takes to fully implement each story.

The question – how do Agile teams estimate the size of each user story? Although estimating by effort hours is very common in traditional projects, it is actually not used very often on Agile projects. A more common approach is to use a technique called “story points”. Story points are an abstract method of estimating the relative complexity of implementing a user story.

Each project team can establish their own story point scale. For example, let’s say user story A has 5 story points (whatever this means). If the team thinks user story B will take twice as many hours to implement, the team would assign 10 story points to user story B. There is nothing magical about the use of 5 story points or 10. Another team might scale these same two user stories at 25 and 50 story points respectively. Even though the numbers are different, the key is that the story points represent relative sizing of the user stories. In both examples user story B will take twice as much effort to implement as user story A.

Once the relative size of a story point is set for an Agile team, the team can estimate how many story points they can deliver in an iteration. Again this is relative based on the scaling process used for the story points themselves. Using the above example, the team that estimated stories A and B to be 5 and 10 story points might be able to implement 45 story points in an iteration. On the other hand the team that estimated those two stories at 25 and 50 story points might be able to implement 225 story points in an iteration. O

The general characteristics of story points include:

  • Story points represent the total amount of work required to fully implement a user story.
  • The stories are estimated independently by team members and the team drives toward a consensus opinion.
  • If a user story is too large to be implemented in one iteration it needs to be broken down into two or more smaller stories.
  • Many of the estimating models are designed as games that are interesting and engaging for the project team.

Over the course of a few iterations the Agile team quickly understands how many story points can be completely implemented in one iteration. This is known as the team “velocity”.

Summary

Agile projects have a number of unique techniques that are not easily transferable to traditional waterfall projects. One of these techniques is the estimation of user stories using abstract story points, and the use of story points to determine how much work can be completed in an iteration (velocity). These are simple yet very effective techniques that are the hallmark of an Agile project.

TenStep Agile Services (English only)

TenStep has offered Agile speaking, training and consulting since 2001.

Training

Agile Overview Learn the basics in 1-2 days.
Prep for the Agile Certification Exam Learn what it takes to pass the PMI-ACP exam.

Content

Agile Combo. A 110+ page e-book and e-learning session.

Do You Take Risks? Then You Understand Positive Risk

/in /by

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.

Risk Management Worksheet

/in /by

The use of a risk management worksheet is similar to that of a risk management plan, but for big projects, they will have a limit of effectiveness. This is because of the size and number of the risks involved that could impact the larger business ventures.

You can use the risk management worksheet as an accompaniment to your risk management plan. It would be like a cheat sheet of sorts. To be effective you will have to list all of the possible risks you already placed in your risk plan. Not only will the names and nature of the risks that could impact your project be listed on this worksheet, but also the paths for mitigation. This will allow for an even faster response to the risks damage when they impact your project.

Not all of the information in your risk management plan needs to be listed on the risk management worksheet. Some of the items in the plan can be eliminated. The leading ones are the risks that have already been mitigated before the project enters its execution phase of its project lifecycle. The mitigation can be from someone in your project team or an outside source. The only ones that will fall into this category will be the risks that need no action taken if and when they impact your project.

One of the most important components of the risk plan that should be on the risk management worksheet is the contacts for the third party vendors who are the alternates for supplying your raw materials. The risk that makes an impact could be as simple as a vendor not meeting your schedule. To keep your project going, you will need to fill in this gap of supplies with another party. The sooner you contact them, the faster you will be receiving the raw materials you need for your deliverable.

The risk management worksheet is just another handy little tool the project manager can use to keep their business venture progressing towards a successful conclusion. Like all tools, the proper use of it and acting fast will make all the difference in just how effective it really is.

 

Webinar: Project and Portfolio Management Using TenStep and Planisware

/in /by

When your portfolio of work consists of one or two dozen projects, it’s possible to keep track of what’s going on with spreadsheets or simple desktop tools. However, tracking projects, resources, and costs with standalone tools becomes increasingly more difficult as your project pipeline grows.

This webinar will focus in two main topics. First we’ll discuss the critical connection between the project management and portfolio management processes. In the second part of this webinar, we’ll demonstrate how a solid end-to-end PPM software can support and even automate your project and portfolio management processes. The demonstration will be provided using Planisware, Enterprise Project, Product Portfolio Management software solutions that support the end-to-end governance of company portfolios.

Join Tom Mochal, President of TenStep, and Michel Delifer, Sales Director at Planisware, in a discussion of these important topics.

TenStep webinars… attend… learn something.

Date: 4 December 2014
Time: 12:00 (Atlanta time) / 6:00 PM – 7:00 PM CET
Live participants will receive 1 PDU.

[button align=”left” link=”http://www.projectmanagementwebinars.com/freewebinars/2014-12-04ProjectandPortfolioManagementUsingTenStepandPlanisware.wmv” button color=”white” icon=”file-movie-o”]WATCH RECORDING[/button]

Six Reasons Companies Struggle Implementing Project Management

/in /by

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