ICPM

This email address is being protected from spambots. You need JavaScript enabled to view it. This email address is being protected from spambots. You need JavaScript enabled to view it. The International Community for Project Managers
Brought to you by TenStep, Inc.
2363 St. David's Square
Kennesaw, GA 30152
877-536-8434 or 770-795-9097

This email address is being protected from spambots. You need JavaScript enabled to view it.
You are here: Home Blogs Displaying items by tag: Project management
Project Management Blog
Obviously your project is in trouble if you are missing deadlines and consistently exceeding the estimated effort and cost to get work done. However, you may have a project that actually appears to be on schedule, yet you are concerned about potential problems down the road.

There are things that you can look for that will give you some sense as to whether there are potential troubles lurking. At this point you can’t really call them issues or problems, but they can be identified as risks that have the potential to throw your project off in the future.

Are You Falling Behind Early in the Project?

Many project managers believe that if they fall behind in a project early on, they can make up the time through the remainder of the project. Unfortunately, there is a natural tendency to fall behind as the project progresses. First of all, the more distant you look, the less accurately you can estimate. Second, there are always unexpected items that come up during projects. It is a good idea for project managers to try to get ahead of schedule early on in the project with the expectation that they will need the extra time later.

If you find that you are falling behind early in the project, your best remedy is to start developing corrective plans immediately. Don’t sit back passively and hope you can make the time up later. Be proactive instead, and put corrective plans in place today to get back on schedule.

Are You Identifying More and More Risks?

We are trying to identify warning signs that a project may be in trouble, even though it appears to be on schedule. If you have a multitude of issues that you are addressing today, you probably are not on schedule. However, you may be fine now, yet face a number of identified risks in the future. Of course, all projects have some future risks. However, if you see more and more risks as the project gets going, this could be a big warning sign that your project is in trouble.

If you face this problem, the good news is that you are identifying risks while there is still time to address them. Even if you have an abnormal number of risks, you may still be okay if you really focus on managing them successfully.

Customer Participation Starts to Fade

Your customer needs to be actively engaged during the planning process and the gathering of business requirements. If you cannot get them excited about participating during this timeframe, then you are really in trouble. However, many times the customer begins to become disengaged when the project is a third completed and the project work starts to turn more toward the internal project team. It is important to keep the customer actively involved. The project manager needs to continue to communicate proactively and seek the customer’s input on all scope changes, issue resolution, and risk plans. The customer also needs to be actively involved in testing. The project manager needs to make sure that the customer stays involved and enthusiastic. Otherwise testing and implementation will be a problem down the road.

Morale Starts to Decline

On the surface, if you are on schedule, there is no reason for morale to be going south. If you detect that this is happening, it could be a sign that you are in trouble. You need to determine the cause. Morale might be slipping because people are being asked to work a lot of hours to keep the project on track. That would tend to be an indicator of trouble in the future. It is also possible that the team may think the future schedule is unrealistic. In any case, poor morale needs to be investigated and combated.

Summary

One of the important responsibilities of a project manager is to continually forecast into the future to update the schedule, identify risks, and manage expectations. A project that seems on track today could have major problems tomorrow. Keep your eyes open for these warning signs that things are worse than they appear. If you recognize them ahead of time, they can all be classified as project risks, and can be managed and controlled in a manner that will allow your project to succeed.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
Earned Value is a way to measure the progress of a project with greater precision and accuracy than is typically available. Earned Value metrics can be combined to show whether the project is on schedule and on budget. If it is not, Earned Value metrics can indicate the percentage the project is over or under budget and the percentage the project is ahead of or behind schedule.

Let’s look at the environmental factors that must be in place before Earned Value can be implemented, and examine why these factors can work against the adoption.

Project Factors

On the project side, the biggest factor to consider is the simple rule of “garbage in, garbage out” - you need to start with good project data to use Earned Value metrics effectively later in the project.

  • Schedule. You need a good schedule with good estimates for all of the underlying activities. If you are imprecise with your effort and cost estimates, Earned Value calculations will not work well for you.
  • Scope change management. If you create good initial estimates for the work activities, but then you do a poor job of managing scope, the Earned Value calculations are going to go bad in a hurry. On the other hand, the Earned Value numbers would show the effects of taking on more unapproved work, and so they would start to raise a problem flag early in the project.
  • Capturing actual effort and cost. Many project managers build good schedules and manage the schedule based on completing the activities on time. Many projects don’t capture the actual effort hours associated with completing each activity. Obviously that is needed for Earned Value calculations to work.
Organizational Factors

It is difficult to implement Earned Value on one individual project if the entire organization is not behind it. First of all, it takes time to capture and calculate Earned Value numbers and you may find that this extra time is not appreciated by your manager – even if you could show that the extra time invested would ultimately result in a better managed project. Likewise, the resulting Earned Value numbers would be of interest to the project manager, but most other stakeholders in the organization won’t have a clue as to what the formulas mean.

From an organizational perspective, the implementation of Earned Value into the organization requires a change in the way people perform their jobs. As such, it needs to be seen as a culture change initiative. First and foremost in a culture change initiative is sponsorship and leadership. You must have a champion who is willing to be the sponsor and who will ensure the proper training, processes and incentives are put into place so that Earned Value concepts are applied consistently across the organization.

The work required to implement Earned Value also depends on the processes that exist in your organization today. If your organization is not used to creating detailed schedules with accurate effort, cost and duration estimates, it will take some work to build that skill. Likewise, if people aren’t used to tracking time and costs on an activity level, it will require major changes to how team members account for and track what they are working on. To implement time reporting may also require new tools and processes be established.

Weighing the Cost Against the Value

Executives should determine whether Earned Value is right for their organization.

First, they should look at the effort and cost associated with implementing the concepts successfully. As described earlier, depending on where the organization is today, the cost could be substantial and the timeframe could be quite long.

Second, they need to determine what other core skills will need to be enhanced to make the Earned Value concepts work. For instance, project managers may need to learn better estimating techniques for the calculations to be relevant. They may also need to learn better techniques for building more accurate schedules.

Third, after understanding the effort and cost, the executive need ask themselves what incremental value would be gained by more precisely managing project progress. For instance, if a project manager manages by end date, they should pretty much know whether the project is ahead or behind schedule. So, if the project manager can estimate that a project is three weeks over schedule, is there really much additional value with knowing that the project is trending three weeks and two days over schedule, as shown through Earned Value calculations? Likewise, a project manager may estimate a project is $10,000 overbudget, while the Earned Value calculation might show that the project is trending at $10,615 over budget. In other words, if the project managers have a decent skill set today, what incremental value will be gained by going to Earned Value?

Summary

Perhaps it is no wonder that organizations see a lot of pain in moving toward Earned Value and not a corresponding amount of incremental value. Given the alternative initiatives and the usage of resources, it is not surprising that in most organizations, a move toward Earned Value would not be one of the top priorities. It is a good concept and it makes sense intuitively. However, from the perspective of most companies, the pain of implementation seems to outweigh the value gained.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
Why is it that most of us don’t have a problem working 70 hours a week taking care of our customer’s needs, and yet we have difficulty writing a decent status report? There are two major problems. First, some people do not have great written communication skills, and they are not comfortable writing. However, in most cases, the problems with communication are not a lack of skills, but a lack of focus. Many project managers do not appreciate the value of communicating proactively. When they do communicate, it tends to be short and cryptic, as if they are trying to get by with the minimum possible effort.

Keep the Reader in Mind

The key to communicating is to keep the receiver as the focal point – not the sender. Try to think about what the receiver of the communication needs and the information that will be most helpful to him. If you are creating a status report, put in all the information necessary for the reader to understand the true status of the project, including accomplishments, issues, risks, scope changes, etc.

In many organizations, the project manager needs to communicate with people at multiple levels. If so, remember that a one-size-fits-all approach may not apply to communication. You may need to modify the communication content between managers and executive managers. For instance, you may send a one-page report to your direct manager and major clients showing the project status and financial situation. This may be summarized to a half-page or even one paragraph for executive management.  

Include Useful Information - Not the Mundane

Try to focus the status reports so that the information in them can be used in the decision making process. Ask team members (and yourself) whether the information on the status report is there to communicate something valuable, or if it is just taking up space. With that in mind, what types of information should be included?

Typically the status report should include the following information:

  • Project name / project manager / time period / project description: This is all basic information that needs to be included each time so that people know what they are reading.
  • Overall status indicator: Typically there is a very short indicator that reflects the overall status of the project. A common way to express this is with color codes such as green (on track), yellow (caution), or red (problems).
  • High-level status summary: The top portion of the report should provide summary information regarding the overall project. Make sure that the questions are worded in a way so that a project that is on-track will answer either all 'yes' or all 'no'. Notice that the questions are focused on the present and future state of the project – not the past. For instance:Comments: Provide more information for any questions above that were answered negatively'.
    • Will the project be completed on time?
    • Will the project complete within budget?
    • Will the project deliverables be completed within acceptable quality levels?
    • Are scope change requests being managed successfully?
    • Are project issues being addressed successfully?
    • Are project risks being successfully mitigated?
    • Are all client concerns being addressed successfully?

Significant accomplishments this period: List major accomplishments from the previous reporting period. If the planned accomplishments from last period were not completed this period, the project manager should provide reasons as to why.

  • Planned accomplishments for next period: List major planned accomplishments for the next reporting period.
  • Additional comments or highlights: Describe any other comments that the reader should know that would not be reflected in the status report in the previous fields.
  • Attachments: There are many other project management reports that might be of interest to the reader. Again, make sure to remember your audience. For instance, the project schedule might be of interest to some of your readers, but is probably too much information for everyone. Likewise, your readers are probably interested in summary financial information, but not at a detailed level. Other potential attachments include the Issue Log, Scope Change Log, project metrics / statistics, earned value reports, and any other reports required by your company.
Focus Forward

If you are on a support team, your status reports are going to focus on the prior period up to the present time. That is because support is typically reactive and it is hard to know what you might encounter in the future. However, a project status report should focus more on the present and the future. Prior deliverable accomplishments are of some interest to the reader; however, they are more interested in what it will take to complete the project.

Summary

Writing good, effective, and objective status reports requires focus and diligence on the part of the project manager. The purpose of the status report is to communicate the true nature of the project – not how you wish it was. When you write a status report, include information that is of value to the readers and will help them understand what is going on. If there are issues or risks, they should be communicated as well. If your status report is too short, or at too high a level, the reader will not fully understand the status and may have to ask follow-up questions. Creating your status report allows you to keep everyone informed about the true status of the project at a particular point in time. Make sure that you communicate effectively so that the readers have an accurate understanding of the project.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
It should normally be clear that training will be provided when the project solution is about to be deployed. However, what typically happens is that the work associated with training is also all pushed toward the end of the project. The result is that you may feel rushed to create the training material, and the training might not seem as effective as you wanted.

The key to effective training, as it is with other aspects of the project life cycle, is to start the planning process early. If you wait to consider your training needs until the end of the project, you will not have enough time to do it the way you would like.

Start with the strategy (maybe)

The first possible deliverable to consider is a Training Strategy. You would want to consider this level of planning if your project is complex and there is a large training component. For instance, if you are involved in a project to implement a new Customer Relationship Management (CRM) application, this type of application obviously has a dramatic impact on the Sales and Marketing users. You may want to create a Training Strategy first to make sure you have an agreement with the customer on the overall direction and approach to take.

All strategy documents on a project are typically done in the Analysis Phase. So, early on, as you are getting your business requirements, you also get requirements for the necessary training. These requirements are used to create an overall strategy, which should then be approved by the customer.

As you probably know from experience, most projects do not have such a complex training situation, and so the Training Strategy document is not needed for most projects.

Create an overall Training Plan

The Training Plan is created during the Design Phase. If you have a Training Strategy, the Training Plan simply contains the additional details required to make the strategy real. If you do not have a Training Strategy, then the Training Plan typically has some initial aspects of strategy, and then quickly gets into the details. The Training Plan would include a description of the audience you are trying to reach (this could include customers and IT staff), an overview of the training needs, and s plan for how you will satisfy the needs. You also need to define how the training will be developed and executed, as well as when the training will be deployed. Remember that training does not only imply stand-up, internal classes. You may consider bringing in outside trainers, using vendor classes, coaching sessions, webinars, how-to instructions, frequently asked questions, computer-based training, etc.

Develop the training content needed

If you complete the planning documents ahead of time, you will be ready to develop the training content at the same time that you are developing the rest of the solution. The Training Plan is not a schedule,.so you will need to add the remaining development and deployment activities to your schedule. However, at this point the confusion has been lifted and it should be clear what has to happen in the training arena.

Test the training content, if necessary

In most instances, the first time you deploy training is actually in a live environment with real users. However, sometimes the training is offered first to an internal group, or even the project team. This serves as a test of the material to make sure that it flows well. It also helps prepare the instructors so that they will be more comfortable delivering the training to the end users. If you are going to hold webinars or any other type of distance learning, you can test the technology and the delivery at this time.

Implementation

It was mentioned earlier that you typically want to train your users right before the solution is implemented. However, this is a generalization. Actually, the training deployment is based on the timing specified in your project Training Plan. However, what you should notice is that this approach reduces the chance that your training will be rushed, or that your training will somehow miss the mark. Assuming you followed the prior steps, at this point in the project you should have developed (and perhaps even tested) your training content, and you should be ready to go regardless of when the training is needed.

Summary

What you see in this approach is that the training delivery also follows a life cycle. Just as you do not want to jump straight into your project Construction Phase, you also do not want to wait to the last moment and then quickly jump into building the training content. Some up-front planning is the key, as well as making sure that you do any construction of training content at the same time that you are constructing your solution. Just as you ensure that the implementation of your final solution will go smoothly, you can also ensure you will have a smooth training deployment by using this structured approach.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
Traditionally, risks represent potential events or circumstances that exist in the future that could have a negative impact on your project. They are not problems today (if they were, they would be issues, not risks), but they have the potential to become problems in the future. On the other hand, they are not definite problems. There is a chance that the risk will occur, but there is a chance it will not. Identifying the risks that you need to focus on is a combination of identifying the risk event, determining the potential impact to your project, and determining the probability that the risk event will actually occur. When you are done with this exercise, you look for high-risk events and put together a plan to deal with each one.

Let’s take an example. Say you have a supplier that you are counting on to provide raw materials to build a prototype. However, the supplier has a union contract that is expiring in the next 60 days. There is a risk that the supplier will have a strike that will disrupt shipments. You need to identify this as a risk, estimate the probability of occurrence (perhaps this will increase or decrease over time), determine the impact to the project if it occurs, and then put together a plan to minimize the impact on the project if it occurs.

Is risk always a bad thing?

Now let’s get to the concept of positive risk. After all, isn’t everyone supposed to be an intelligent risk taker? Isn’t it right to push the envelope? Isn’t it better to have tried and failed than to have never tried at all?

These statements get to a difference between how risk is typically identified from a project management perspective, and how it is utilized in culture. The concept of risk in language is broader than how it is typically used in project management. This broader definition takes into account the concept of positive risk, or opportunity risk.

Positive risk

Negative risks are potential future events that could impact your project negatively. In general, they are to be avoided (although there are different risk strategies, depending on the individual risk). Positive risk, on the other hand, refers to risk that we initiate ourselves because we see a potential opportunity, as well as a potential for failure. This is what we are referring to when we say that we are intelligent risk takers.

New technology may provide a good example. Say that you have a software development project that is scheduled to take 90 days to complete. Your business client would rather the project be delivered earlier, and would get more value if it were delivered earlier, but they understand that 90 days is how long the project will take.

One of your team members has an idea. If you utilize a new software-testing tool, it is possible that you can deliver the project in 60 days instead of 90 days. If this were a guaranteed solution, you would jump on it. However, there is risk, since it is the first time you have used the tool. There is a lack of expertise and a start-up learning curve. It is possible that if the tool does not work out, the project could end up taking 110 days to deliver. What would you do?

Of course, you don’t have enough information to make the decision now. However, this example illustrates the concept of opportunity risk. The business client will accept delivery in 90 days. If you decide to use the tool, it is a risk you are introducing yourself, based on an evaluation of the chances of success and the impact of success, versus the chances of failure and the impact of that failure. When it is said that we are intelligent risk-takers, it is these types of decisions that are being addressed.

The debate is on

Even though you may commonly think of project risks as having a negative connotation, you can also use risk management to identify and quantify potential positive risk. If you would be the one introducing the risk, the risk management plan would be within your control. You and your client can determine if you want to accept the risk after understanding the risk plan, the chances of success, the payoff if you are successful, and the impact if you are not successful.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .

Published in Blogs
Tuesday, 16 December 2014 15:17

Allocating Resources in a Matrix Organization

In large organizations, or on large projects, you may have the luxury of full-time resources for your entire team. However, in many (or most) situations, the project manager must utilize shared and part-time resources to complete the work. Some resources may be working on multiple projects, while other resources may also be working in support (or operations) roles. The process of gaining and retaining resources in this environment can be difficult, and is partly the result of how your organization is structured.

Let’s look first at the three basic organizational structures - functional, project, and matrixed. In a functional organization, people are organized into functional specialties such as the Finance Department, Marketing Department, and Information Technology Department. Projects are staffed with people from within the organization. Generally, your functional manager is also responsible for the success of the projects.

In a project organization structure, the people are all aligned around major projects. For instance, you may have an organization built around the building and deploying of a weapons system for the Department of Defense. All the people that are required for the project to be completed are assigned full-time to the project. This might include IT, manufacturing, procurement, finance, etc. The overall project manager is the functional manager as well.

The third option is a hybrid of the two – the matrix organization. People are assigned full-time to a functional organization, but can be temporarily assigned full-time or part-time to a project as well. In this case, the functional manager may be responsible for part of a team member’s workload, and a project manager may be responsible for assigning the work associated with the project. The matrix is especially efficient if your project does not need a full-time commitment from people in the supporting organization. These people can be used part-time on projects. (They may be working on enhancements, but these fit the definition of small projects.) A matrixed organization also works well when your projects are smaller and do not necessarily need full-time resources.

The matrixed organization can be the most efficient at utilizing and leveraging people’s time and skills. However, it only works if the functional manager and project manager (or multiple project managers) recognize the challenges and work together for the company’s overall benefit. The two areas to focus on are planning and communication.

Planning

In a matrix organization, it is important to maintain a planning window of upcoming projects and an estimate of their resource needs. If your staffing requirements fluctuate a lot from month to month, or if the projects cannot be forecast many months in advance, you can at least plan using a three-month rolling window. You should then update and refine the plan on a monthly basis. The closest month should be pretty firm. Two months out should be pretty close. Three months out and beyond is best guess.

On the other hand, if the projects in your organization are typically longer, and your staffing plan is well understood, you may want to maintain a three quarters (nine month) planning window and update the plan every quarter. The planning process should include the appropriate project managers and functional managers who tend to share a common pool of resources.

Communication

After the planning comes the proactive communication. Remember that in a matrix organization, project managers need resources to do their work, but they do not own them – the functional managers do. So, the onus is usually on the project managers to make sure that the resources are available when they are needed, and that there are no surprises. For instance, if you and the functional manager agree that a specific set of people will be available for one of your projects in two months, don’t just show up in two months and expect them to be ready to go. In fact, you should expect that they will not be ready if you have not communicated often and proactively. The project manager should gain agreement on resources two months in advance. The resources should be confirmed again at the next monthly staff allocation meeting. The project manager should double-check resources again two weeks before the start date, and follow-up with a reminder one week out. You are much more likely to have the resources available when you need them if you take these proactive steps.

Planning Tools

Secondary to getting a good planning and communication process in place is worrying about a tool. There are resource allocation tools on the market, but for small to medium organizations a good spreadsheet will work fine as well. The spreadsheet might have people down the rows and work across the columns (or visa-versa). Each month (or quarter) could be on a separate tab in the worksheet. For each month (or quarter), you plan the projected work allocation for each person, ensuring that all work is adequately staffed, and that all of your resources are fully engaged.

For larger organizations, a specialized resource/workload planning and tracking package may be appropriate. You can also document a skills inventory for each person so that you can see who might be a potential fit for projects coming up in the future.

Summary

Many companies and organizations struggle trying to optimize the people allocation in a matrix organization. You can get software to help make this easier. But software is just a tool. Overall staffing success in a matrix organization depends on having good planning processes in place, maintaining a partnering relationship between the project managers and functional managers, and communicating proactively and effectively.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
Tuesday, 02 December 2014 19:43

When to Implement a Requirements Freeze

There are different opinions about when to implement a requirements freeze. When considering a freeze, it is important to keep the following facts in mind.

You Cannot Freeze Business Change

Business is always changing, and the project solutions that are built must reflect these changes. However, you can still freeze change requests. Freezing change requests is simply a technique to bring closure to the project. Remember that when you build a solution for your client, the project only represents the initial steps in the product lifecycle. Once the system goes into production, there may be follow-up phases to the project, or the solution will go into a support and enhance stage. This stage could easily end up representing ninety percent, or more, of the entire solution lifecycle. The enhancement process is the way that the application is changed over the long-term. So, do not seek to freeze business change overall, only to freeze changes that would extend the life of the initial project. If changes are needed after the project freeze is implemented, they go on the backlog to be addressed later as enhancements.

All that being said, you do not want to deliver a solution that does not meet the business needs. That would not make sense either. If you implement a requirements freeze, you must also have a process in place for getting around the freeze. What you are really doing is gaining agreement with the client sponsor to raise the threshold for scope change management. During the freeze, for instance, it may be that all change requests need to be approved by the sponsor personally. If the sponsor understands the benefit of the change request, as well as the cost and impact to the project, he may still approve the request if it is important enough. However, even important changes may not get approved during the freeze. What may happen instead is that the change will be prioritized high as part of an enhancement request after the solution goes live.

Fixing Errors is not Affected by the Requirements Freeze

You may wonder whether system testing is the right time to implement a freeze. Remember that the freeze is on business requirements changes. Of course, if you find problems or errors in the system test, they need to be corrected. System testing is a time when you do stress testing, usability testing, documentation testing, performance testing, etc. As an example, during requirements testing you may find that you misinterpreted a requirement, which will require a change. This is not a change to the requirements, but the correcting of an interpretation error. This may be allowed. During stress testing, you may find that your hardware is not powerful enough to take the load. This may require changes to the system configuration, or a change in how the transactions are processed. Again, this may be required under the freeze.

However, hopefully your client is not adding new business requirements during system testing. When you get to system testing, in many cases you have to retest when changes are introduced. For instance, if a change request is allowed during system testing, you must make the change, unit test it, run integration tests, and potentially rerun all the system tests. This is very disruptive, and if possible these changes should wait until the enhancement process after implementation. In fact, at this point in the project, you may even defer some errors that were uncovered during testing if they do not have a major impact to the value of the solution.

Summary

If you consider implementing a requirements freeze, it shows that you have recognized that continued change requests will jeopardize your ability to deliver within your budget and deadline. You can then come to an agreement with your sponsor to allow the team to focus on a fairly stable system for completion of the testing and implementation process. Critical change requests are still allowed, while less critical changes are deferred until after implementation, during the enhancement process.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
Many people work in competitive bidding environments, where the company generates revenue by winning contracts to complete projects and deliver products. Ideally, you would estimate the work on these project as best you could and with an acceptable level of risk.

Unfortunately, you may find that your best estimates are being ignored by management or the sales organization. The problem in that case is that if you win the business, you are probably on the hook to deliver the same level of functionality and quality, but with a significantly impaired budget.

This type of scenario puts the project team in a difficult situation. In this case, you are asked to estimate a piece of work. You deliver the estimate as requested, but then management or the sales people ignore the estimate and make up their own, which you then have to use. This is frustrating because it makes it hard to know the rules and the expectations.

If the pre-defined processes were always followed, life would be so much easier. But the hard part of project management is usually dealing with people issues. It is important to consider the other side as well. The salespeople must feel that they need to reduce the estimates to have a chance at the business. This could be to cover weaknesses in their sales processes, or this may be a fact of life if you are to get any projects at all. Of course, if you have no sales, you have no job.

The following are areas that could help improve the estimating process.

Open a Dialog Regarding Estimating Expectations

Talk to your managers and the sales organization about your team’s frustration, and explain your perspective. Note that they asked you for an estimate, you provided a realistic estimate, and they cut your estimate. This puts you in a position where you cannot deliver what the customer wants for the budget on which they agreed. Ask them for their suggestions in helping to constructively address the situation. You may find, for example, that they do not trust your numbers, in which case you can work with them on the level of detail required to gain their confidence. See if they can help you solve this problem so that both groups are more comfortable in the future.

Negotiate on Functionality

Normally, you could try to reduce some functionality to deliver within a lower budget. This may not be an option when you are dealing with a customer on a fixed bid. However, talk to sales and your managers about any areas of scope that can be reduced or removed from the proposal before it is presented to the customer. If this is a possibility, then there may be a way to commit to less while also being able to deliver the reduced scope at the price needed to win the business.

Look for Process Improvements

There may be things you can do to reduce the cost of development. Can you hire less expensive resources? Can you use new techniques that will allow faster delivery? Are there some testing techniques that would result in less rework? Can errors be caught earlier in the life cycle? You may be able to find ways to deliver the project for less effort and cost through process improvement.

Strive in the Challenge

Get yourself and your team fired up for the challenge of delivering within the reduced budget. You can still prepare a reasonable estimate, but then try to raise the level of team productivity to deliver for less effort and cost. This may be something that can be a challenge in the short to medium term, but it will not work for every project over the long term.

Play the Scope Change Game Well

In some instances, a vendor bids low on the initial contract and then tries to recover costs through scope change management. In other words, they try to force as many features as possible through scope change management, and in each case get more budget money. If the contract and requirements are written loosely, you may find that you can generate significant additional revenue through scope change management, while in fact delivering nothing more than what the customer initially had in mind. On many fixed price contracts, the revenue associated with change requests exceeds the price of the original estimate. Some project managers could bid a project at zero dollars, and then make the entire project look like scope change requests.

Pad the Estimate (But be Careful)

One option I mention but do not endorse is to pad the estimate. For instance, you could increase your estimates by 10% so that if your budget is cut 10% you can still deliver. The major disadvantage here is that the additional dollars in the estimate might make the difference between winning and losing the business. It also introduces deception into the process, and that is not good.

Leave

If this is the nature of the environment you work in, and if you don’t like the business model you work under, you may have to break the stalemate and go somewhere else where you can be more successful.

Summary

Starting a project with less money than you think you need is certainly uncomfortable. On many projects, it would be a recipe for failure. If you are in that situation often, and if it is done on purpose, morale might be bad and it can be difficult to excel. In most situations you have three options – fight for change, adapt, or flee. The options above cover all three of these alternatives.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
Tuesday, 04 November 2014 17:04

Managing Projects with Unrealistic Deadlines

If you are a project manager dealing with what you perceive to be an unrealistic deadline, you will first want to discuss this with your manager and see if there are any factors that are driving the project deadline that may be unknown to you. Sometimes the person who gives you the deadline seems like the bad guy, but see if you can understand the motivation. For instance, there may be a business activity that is driving the deadline. There may be some event occurring that this project needs to support. Or, your project may be one of a number of initiatives that need to come together at a specific time. It does not necessarily make your challenge any easier, but you may find that by better understanding the reason for the deadline, you may have an easier time getting yourself and your team members motivated to try to achieve it.

On the other hand, if the deadlines seem arbitrary and are not the result of some other business driver, then you should find that out as well. Sometimes managers set arbitrary end dates just to provide what they consider to be stretch objectives. However, if the manager is not careful, there will be a time when there is a firm business justification for an aggressive end date, but no one will believe it.

Once you understand the motivation for the deadline date, there are project management techniques that can be utilized to increase the chances of success and better manage expectations.

Try to Adjust the Triple Constraints of Time, Cost and Scope

All projects require some time and cost to create the deliverables agreed to in the project scope. When one of these constraints is out of balance, at least one of the others needs to be adjusted to get them back in alignment. For instance, if your budget is cut, you need to reduce the scope or increase the time to deliver.

If you find that the time constraint is not in alignment with cost and scope, talk to your manager about increasing the resources that are available for the project. Adding resources to the project makes the cost go up, but may allow you to hit the deadline. Also talk to your customer about reducing the project scope. See if there are features and functionality that they can live without for now so that you can deliver the project within the deadline specified.

Utilize Risk Management

When you start a project, the first thing you need to do is plan. One aspect of the planning process includes identifying risks and putting plans into place to mitigate the risks. In your case, if you don't think you can hit the imposed end-date, now is the time to say something. When you do, your manager and your customer start to hear that the end-date is at risk before the project even begins. As part of the risk identification, you can ask the project team, your customer and your manager for their ideas on how to mitigate the risk. Utilizing risk management will help better manage expectations early in the project and also be a way to gather input and ideas for ways that you might be able to hit the deadline.

Utilize Scope Management

On many projects, you start with an aggressive delivery date, and then the project gets increasingly behind schedule because the project manager does not effectively manage scope. Then you end up having even more work to do by the deadline date. Disciplined scope management will ensure that you only have to deliver what was originally promised, and that any approved changes are accompanied by a corresponding increase in budget and timeline.

Aggressively Manage the Schedule

In many projects, you might get a little behind but have confidence that you can make up the time later. However, when you start a project with the deadline at risk, be sure to manage the schedule diligently. You have no margin for error. If early due dates start to slip, you are going to be in trouble early. As you monitor the schedule, treat missed deadlines as issues and work hard to solve the reasons behind the slippage. Again, get your team, management and customers involved. If your customers are causing delays, get more accountability from your business managers for helping to resolve project resource problems. Again, if the problem cannot be resolved perfectly, at least you are continuing to manage expectations.

Look for Process Improvement Opportunities

Lastly, take an honest look at your schedule and your approach for executing the project. Talk to your team, customers, and manager about any ideas they may have for speeding up the project. This will get everyone thinking about being part of a solution. For instance, if your manager insists on having the project completed earlier than the date you have specified, ask him what techniques he could suggest to achieve the earlier end date. Document any suggestions you receive. Show your customer the project plan as well. If you are not achieving the end date they expect, ask them for ideas on how to shorten the project. See if they can help you come up with a solution to the scheduling problem, instead of just passively waiting for the project to be completed.

In addition, perform a self-evaluation of the project schedule and see if there are ways that you can reduce costs and cycle-times. For instance, are there some different development techniques that you could try that might decrease the end-date? Could you utilize a Joint Application Development (JAD) session to gather requirements more quickly than traditional interviewing techniques? Look at how you currently deliver projects and how you manage them to see if there are ways that you can accomplish the project objectives for less time and cost.  

Summary

In summary, although it appears that you are being held accountable for events and circumstances that are not within your control, you do have control over the processes you use to manage the project. First, see if you can balance the early deadline by increasing resources or reducing project scope. Second, proactively manage risk, scope and the schedule so that you can better manage expectations and have the best chance for success given the constraints you are under. Third, work with your manager, customer and project team to evaluate how you are executing the project. You may discover ideas and techniques that will allow you to deliver the project more quic that you might have first thought possible.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs
When a project begins, you must gain agreement with your customer on exactly what you are creating. At a high level, this agreement is reached when the Project Charter is approved. At a low level, the agreement is reached through the approval of the business requirements. Once these two documents are approved, you have enough information to proceed through the remainder of the project.

However, change is inevitable. There are two reasons. First, it is almost impossible for anyone to define ahead of time exactly what the final solution should look like, and so the requirements may change as the solution evolves. Second, overall business conditions change over time. Some of this business change will force changes to the project scope in ways that are not known ahead of time.

So, what do you say when the inevitable changes start to come in? If you say yes without understanding the consequences to the project, you increase your chance of failure. If you say no, you may introduce conflict with the customer, and run the risk of delivering a solution that does not meet the customer’s needs.

Don’t Take It Personally – Use Your Process

When introduced with changes to the project, the best response is to follow a scope change request process. This process should include understanding the business value of making the change, as well as the impact on the project budget and schedule. You can then take this information to the project sponsor (or their designated stand-in) for an approval decision. Scope change management is really the art of letting the sponsor make the decisions once they understand all the facts and implications.

You should establish scope change procedures based on the size of the project. For small projects, you do not need to worry about scope change very much. The project will likely start and end before the business can change much, and most of the requirements are probably fairly well-known. The project manager can quickly evaluate a small change request and work with the sponsor to determine if it should be accommodated.

For larger projects, scope change is a big deal and must be managed accordingly. The entire team, including the customer, must understand when a scope change request is being made. The request should be documented and sent to the project manager. The change is then analyzed and the resulting information regarding the change, the benefit, the cost, and the impact of not accepting the change are brought to the attention of the project sponsor. The project sponsor then determines whether to accept the change. If the change is approved, then the budget and timeline are changed accordingly. If the change is not approved, it is noted as such and the project continues on its way. The funny thing is, if you let the project sponsor decide whether to accept a scope change, he will usually turn the request down. The sponsor understands the need to deliver something, even if it does not meet 100% of his needs. The final solution can be refined over time. In fact, the sponsor typically has a lot less patience for scope change requests than the project manager, and this will eliminate frivolous and marginal scope change requests immediately.

Summary

All projects need to first gain agreement on the scope and the business requirements before scope change management will stick. After that, the key to scope change management is to recognize that it is the process of letting the customer make scope change decisions. The project manager needs to make sure that the appropriate information is presented so that the sponsor can make an intelligent, fact-based decision. Many project managers do a poor job of managing scope because they do not want to offend the customer. However, that should not be a part of the equation at all. Instead, the project manager’s job is to make sure the scope change management process runs effectively, and that the project sponsor has the information necessary to make the best decision possible on whether the scope change should be accepted.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Who's Online

We have 240 guests and no members online

Got something to say?