Tag Archive for: #projectmanagement

Photo by John Schnobrich on Unsplash

Estimating projects is never easy. There are too many variables. Team performance can be inconsistent. And even with sound risk management, issues arise. These variables can require adjustments to estimates for part of a project. Sometimes, re-estimating the entire project might be in order. Here are circumstances when a complete project re-estimation is in order.

• Scope changes by more than 20%. In managing project change, you examine the implications of a single proposed change and propose whether to approve or reject the change based on its cost and benefits. Each change is evaluated on its individual merits. What doesn’t occur is an overall evaluation of the project after many changes have been approved. Multiple changes can increase risk and complexity and the need for personnel and contract management. So, if your project has increased by 20% or more from its original scope, it’s time to re-estimate the remaining project work to assess the aggregate impact of all the changes. That way, you ensure the project is still appropriate for the business.
• Critical team members change. In most projects, there will be business and/or technical team members who are critical to success. If a critical team member changes, you might consider re-estimating the project. You might need multiple people to replace that team member. Or the replacement will be an expensive contracted resource. Either way, you might end up with significant unplanned costs. The replacement resource might take longer to deliver their assignments due to a lack of internal business knowledge. Re-estimating after critical personnel changes ensures realistic expectations for the project.
• The project has varied by 30% or more from your initial project estimate. Don’t continue to use an estimate that isn’t accurate enough. If you’re variance is over 30% from your original estimate, it’s time to re-evaluate the project’s viability. Revisit all your estimates. Use the difference between actual performance and your estimates to revise remaining work estimates. Look for opportunities to cut scope. While you want to deliver value to offset the money you have spent, it may not be feasible. The project should continue only if future spending will justify the business value.
• The project intent changes. Projects can go a different direction due to business strategy changes. Or a change of sponsor can alter your project’s direction. The priority of requirements can change or new requirements arise. The team members and project name are the same, but you could be managing a very different project. If so, it’s time to re-estimate! Evaluate risks and examine the tasks needed to meet the revised expectations, so you can verify that the altered project can meet business expectations.

Have you ever re-estimated an entire project? If so, why, and how did that turn out. Share with us in the comments section. 

For more about estimating, check out my Project Management Foundations course.

Photo by Quick PS on Unsplash

Critical projects sometimes die prematurely when blockers prevent projects from getting management approval. Here are some tips for addressing these common approval blockers.

• Your organization hasn’t established project success metrics. A lack of success criteria can raise obstacles to project approval. Is the payback period 1 year or less than that? Do you need a significant reduction in the risk of using old processes or systems? What does significant mean? Do projects have to achieve a cost reduction of greater than 10%? Or is it a combination of these? Sometimes, the best way to get a project approved is to propose success criteria so management can talk about them and make a decision.
• Conflicting stakeholder goals prevent agreement. Goal conflicts between senior stakeholders are common. Financial personnel might focus on reducing costs, while marketing personnel want to spend more on initiatives to increase profit. Stakeholder conflicts that aren’t understood or identified can kill your project. They may have started from past projects or personality clashes. Work with your sponsor to facilitate conversations between conflicted stakeholders. Meet one-on-one with influential stakeholders who aren’t enthusiastic about your project. That way, you can identify these conflicts and work to resolve them.
• Past project failures. Many organizations have a poor project success rate. Stakeholders remember the pain and pressure of those failures, which makes them hesitant to take on new projects. Work to understand their fears. Review documented lessons learned, but don’t assume they tell the full story! If possible, talk with the people involved in past project failures. Personnel and contractor failures might not be identified. Do research to understand these failures and put risk plans in place to address them. Discuss how you will manage the project differently. 
• “We are too busy.” Does busy mean the organization is productive? Often, antiquated processes and languishing projects persist. Time wasters may contribute to being busy, but don’t help the business. People don’t like stopping a project that has consumed resources without delivering value. As a project manager, you can do your homework to help your sponsor why they should stop a project. This can free up critical resources to work on more viable projects. If that doesn’t work, at least it raises awareness of the need to examine whether busyness is producing anything of value. 

Have you encountered other obstacles to project approval? If you have tips or questions, share with us in the comments.

For more about project approval, check out my Project Management Foundations course.

Photo by Mika Baumeister on Unsplash

Spreadsheets have so many uses, but project scheduling tool is not one of them. You can use one to create something that looks like a Gantt chart schedule. But you can’t manage that schedule without a ton of menial work. Here’s why you should use a scheduling tool rather than a spreadsheet:

• You can manage lag and lead times. Task relationships aren’t always straightforward. Scheduling tools manage this automatically through lag or lead time between two tasks. Say you submitted a building permit application. You need to receive approval before starting your first construction task. In a scheduling tool, you can add lag between the predecessor and successor to automatically maintain the delay between the tasks. You can also overlap tasks. For example, you have to draft a long book chapter. Editing that chapter could start before the entire chapter to shorten the schedule. Lead time specifies when the successor task can start before the predecessor tasks finishes. For the chapter, you add lead time between the two tasks to give the author a head start before the editor starts editing the chapter. With a spreadsheet, you would have to keep track of lag or lead time as the schedule changes.
• A scheduling tool automatically updates start and finish date when you input actuals. Project schedules change all the time. Tasks go more quickly or take longer than expected. Resource availability isn’t what you planned for. A good scheduling tool automatically recalculates dates to show the revised schedule. Try this with a spreadsheet and you’re in for a resource-intensive, and error-prone exercise even for a small project. You can also use a scheduling tool to explore what-if scenarios. Have a change you’re considering that would add or delete several tasks? Make those changes with a scheduling tool and evaluate the results.

• Calculate costs based on actual hours spent (without having to building those calculations in a spreadsheet). Scheduling tools have built-in functions to calculate costs. The calculated cost is based on the time spent to complete tasks that you enter in the tool) and the hourly rates for each person. Scheduling tools can also calculate equipment and materials costs. The tool calculates overall project cost from the individual task costs.
• Automatically compare the status of your project to your baseline. Knowing where you are on the project compared to what you originally planned is crucial to keeping a project on track. The differences, called variance, are a fundamental part of status reporting. With a scheduling tool, you can save a baseline of your schedule, and then compare the actual time and cost spent to that baseline. A scheduling tool can also forecast the variance from the baseline finish date and cost based on where the project is today.

For more about what several scheduling tools can do, check out my Project Management: Choosing the Right Online Tool course.

Photo by Katherine McCormack on Unsplash

You probably use a Work Breakdown Structure (WBS) in your projects, but sometimes, it isn’t enough. A product breakdown structure is helpful when you need to deliver a complex solution. A Product Breakdown Structure (PBS) is like a WBS, except it shows product details and how its components fit together. Here are the benefits of using a PBS.

• It creates a common vocabulary for discussing the product. A PBS uses nouns, versus a WBS with verb-based tasks. The PBS defines the pieces that make up your project’s product. Because projects create unique products or services, you probably need definitions for the solution components. The PBS is where you keep those definitions. It also shows how components fit together. This helps reduce errors due to misunderstandings about what the product is and how it will be assembled.
• It helps clarify development assignments. The PBS defines the product components, so the skills needed to build the product are easier to understand. It also helps people come up with ideas for product improvements and refinements. A PBS helps your technical team members understand where their responsibilities begin and end. This saves time and potential confusion as the project progresses.
• A PBS helps identify alternate approaches for building the product. The PBS clarifies what is being built. The process of creating the PBS will help team members come up with ideas for how to build the product, too. It provides different perspectives for how components can be assembled and tied together. It also helps visualize how stakeholders can use the product. Because it shows the tasks you need for construction, it helps you build your WBS as well!
• It helps identify who builds and tests interfaces. The PBS defines how pieces fit together into larger components. Each component needs to be tested to ensure it works as intended. The PBS spells out component relationships, making testing tasks straightforward. And it’s easier to assign testing tasks to team members. The visual nature of the PBS helps prevent overlooking test activities. Those test activities translate to tasks, tying the PBS to your Work Breakdown Structure. This helps ensure you have a complete picture of the product or service, and how it will be built and tested.

Have you ever used a product breakdown structure? Did you receive other benefits? Wondering how to implement one in a project? Share your tips and questions in the comments section.

photo by Anders J on Unsplash

In today’s complex world, projects can become quite large. The problem is large projects are often fraught with issues due to the amount of change they create and the complexity that comes with those changes. Here’s why a series of small projects usually outperform a single large initiative.

• They deliver value earlier. Small projects finish faster, which means the business realizes value sooner. Organizational change also occurs in smaller bites, so stakeholders can digest new ways of working more easily.  
• Changes are easier to handle. A series of small projects provides agile-like results. Learning from one project helps the team improve on the next one. Stakeholders learn from using the project’s products, so they create better requirements. And better requirements improve the value the business realizes.
• Key staff members aren’t as much of a bottleneck. Project assignments often take key operational staff away from their day-to-day tasks. Assigning a critical staff member to a two year project is a challenge. Rolling on and off a series of shorter projects is easier to juggle. That way, you can use internal staff instead of expensive contractors. (And contractors don’t know your environment as well, which can lead to poorer project solutions.)
• Small projects are less complex and less risky. Smaller projects mean smaller scope. Less scope means fewer new functions, fewer stakeholders, and fewer team members. All these mean less risk to the business. However, a series of smaller projects does introduce a different risk. Changing business priorities might mean later projects in the series could be cancelled so some of the original scope is lost.

Have you divided a big project into several smaller ones? What worked well? What didn’t? Share your experiences in the comments section.

For more about small projects, check out my Project Management Foundations: Small Projects course.

Coming up:

Leading with Curiosity

How do you get better at asking questions? Natalie Nixon has invited me to join her on Wednesday December 14th at 12pm ET to explore what it means for a cognitively and experientially diverse team to be curious and creative and what you, as a leader can do to support that effort.