Archive for category: Project Management

Estimating is the bane of a project manager’s existence, because people’s (especially management’s) expectations for estimation accuracy are out of touch with reality. Project managers are expected to produce estimates with little project information and then are challenged when they change their estimates. Bob McGannon and I discussed an approach that makes estimating less controversial with an added benefit of educating management and team members on the realities of estimating.

First, consider a Stage Gate Plan, which triggers a review of a project’s viability when project milestones are reached (for example, completing requirements collection, preliminary planning, and detailed planning). This is a start, but not ideal. Detailed costs that weren’t initially discussed in a waterfall project environment are usually added, drawing scrutiny and challenges. In addition, a Stage Gate Plan isn’t relevant in an Agile project environment. So, what to do?

Voilà: the Estimation Accuracy Plan.

When starting a project, a lack of hard data makes project estimation nothing more than a somewhat refined, educated guess. An Estimation Accuracy Plan is a concise plan that spells out how the estimation process really works. It highlights milestone events when estimation accuracy will increase. For example, in a waterfall project, milestones might include finalized staffing, completed detailed planning, completed competitive bid process, or completed soil analysis before a building foundation is constructed.

The Estimation Accuracy Plan can be applied in an agile environment by building it around features and the priority list. When additional equipment, staffing, or other costs are needed to complete a feature, those costs will be determined, and the overall project estimate can be updated. That way, management can consider the costs and reprioritize features if project expenses become a problem.

This type of plan provides many benefits:

• Shows how much guesswork is part of an initial project estimate and how much project personnel don’t know when submitting an initial estimate.
• Clearly identifies incomplete events that allow for refining estimates.
• Indicates how estimation accuracy progresses over the life of a project. It reminds (or educates) management that estimation isn’t scientific. This plan identifies what will be learned or discovered as the project progresses, and how and when estimation accuracy will increase.
• Demonstrates the financial risk of launching and continuing the project. The estimated cost needed to reach the next estimation milestone is usually well known, so the business can assess the risk of continuing the project beyond the next cost milestone. For example, if three people will work one month to create a detailed plan, the cost to reach that milestone is known. Once the plan is completed, you will have information that helps refine the overall estimate. If a competitive bid process is required for that detailed plan, the cost of conducting the bid is known. The bids submitted from the competitive bid process are still guesswork. The overall project estimate can be refined once the bid process is complete and the costs from the final contract are determined.
• Shows the impact of resourcing and procurement. This plan shows management the variability of major elements in the project’s lifecycle before any significant project spending occurs. It demonstrates the impact of decisions on resourcing, contracting, procurement, and other elements that significantly impact project costs.

Note: When an agile team’s size and sprint times are fixed, the spend rate and costs are easy to calculate. (The cost of team personnel per day multiplied by days worked.) However, when other costs such as vendors, equipment, certifications, or other items affect an agile project, an Estimation Accuracy Plan helps address the same problems that arise in waterfall estimating.

Sample Estimation Accuracy Plan for a Waterfall Project:

• Initial estimate – 4 October 2026
• Vendor personnel rates finalized – 15 October 2026
• Preliminary plan completed – 29 October 2026
• Detailed plan completed – 19 November 2026
• Competitive bid process completed – 9 December 2026

Sample Estimation Accuracy Plan for an Agile Project:

• Initial envision and speculate stages complete – Staffing determined – 21 January 2026
• Prioritized feature list completed – 28 January 2026
• Hardware integration feature sprint (4th sprint) – 25 March 2026
• Server configuration feature sprint (6th sprint) – 22 April 2026

Note: A re-prioritization of features occurs at the end of each sprint, so the sprint numbers, dates, and therefore the overall project estimate refinement schedule will change if those feature dates change.

We would love to hear your thoughts about using an estimation accuracy plan. Add your thoughts in the comments section.

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

 

Coming Up

My course Project Management Foundations has been updated with several text-based entries in the Table of Contents. You can read up on the hybrid project management lifecycle, get tips on creating a project information system, review a checklist for effective meetings, and more.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 92,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

Requirements are supposed to represent business needs, but sometimes, they reflect a solution stakeholders believe will help them. For a project to create value, you need to make sure requirements convey business needs not solutions. To scrub proposed solutions from your project requirements, make sure that:

• Requirements are written as “what statements,” not “how statements?” A requirement statement shouldn’t have any process constraints. The requirement should describe the desired outcome or condition, leaving the playing field open for different solution approaches. For example, “Shortening the manufacturing time by 15%” or “Reduce costs by reducing the parts inventory required to maintain the manufacturing line”. How to reduce the required parts inventory (for example, with computer modelling or by changing to longer-lasting parts) isn’t mentioned.
• Any constraints included in the requirement statement are in business terms. For example, increase profit by 15% without increasing expenses by more than 10%. 
• There is a clear link between the requirement and a business need, problem, opportunity, or constraint. Also, all the stakeholders understand the reason for the requirement. Typical business needs are stated as profit, cost reduction, time, regulatory compliance, market share, and so on.
• The requirement describes a measurable outcome. Keep in mind, done/not done doesn’t count as measurable. For example, a target for reducing parts inventory could be 20%, 30%, or to where costs are reduced by $300,000. Actual results can be described as below, at, or above those targets. In comparison, installing and configuring a computer system (a solution, using technology) to optimize inventory levels is either done or not done. It does not directly reflect a business outcome. 
• The requirement allows for creativity or agile learning. Requirements that don’t constrain approaches to solving a problem are the best examples of leaning into the “what” approach. For example, “Reduce the cost of maintaining an aircraft at the boarding gate” constrains creativity. The improvement must apply only when the aircraft is at the gate, rather than maintenance performed in a hangar. Note: There could be business instances when a specific condition like that is a true requirement. But try to avoid them unless necessary. The flexibility to be creative is important, especially in an agile world, where solutions can evolve during a project.

Homework! Go through the requirements for one of your projects, present or past, and see whether any “how to” requirements snuck in. If so, practice turning those into “what” requirements.

For more about defining requirements, check out Daniel Stanton’s Project Management Foundations: Requirements course.

 

Coming Up

My course Project Management Foundations has been updated with several text-based entries in the Table of Contents. You can read up on the hybrid project management lifecycle, get tips on creating a project information system, review a checklist for effective meetings, and more.

 

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 91,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

Using contractors and other vendors can be a great option if you need more people or people with specific skills. However, cost goes beyond the hourly rate you pay. And vendors introduce risks to your project. Here are things to consider before bringing on vendor personnel.

• Examining alternatives, negotiation, contracting, and performance monitoring. Hiring a contractor or vendor takes time. You have to find a person with the right combination of technical and business skills and a personality that fits into the culture of your organization. Then, there’s negotiating the contract and monitoring the vendor’s performance against that contract. Note: Pre-negotiated contracts with vendors make it easier, but you still have to review candidates to find the right person.
• Stakeholders relying too much on vendors. With vendors who have technical and industry experience, business stakeholders might presume that the vendor understands the project requirements in detail. The vendor might use the correct local business vernacular and anticipate the organization’s needs, which lulls stakeholders into feeling they don’t have to participate in the project. They step back and rely on the vendor to represent them. But in most cases, the stakeholders’ requirements and needs of the stakeholder can differ greatly from the vendor’s perception. Be sure to take time and care to verify the stakeholder needs directly, which means conducting in-depth interviews with stakeholders.
• Preventing IP from leaving the building. Vendors are often exposed to and help craft new processes or configure technical tools for the organization. But think about the cost if that intellectual capital walks out the door and is permanently lost. To avoid this, assign in-house personnel to mirror their vendor colleagues. That way, they understand the processes and technical changes a vendor creates for the business and keeps the IP in the house.
• Mitigating risks. Vendor personnel might see confidential information and misuse it or report it to other entities. In addition, vendor personnel can leave at any time to take work for a different client or to change jobs. Of course, in-house personnel can change jobs, too. But you have no control or detailed knowledge of the vendor’s team members and their personnel plans. To avoid these issues, prepare backup staff alternatives and be ready to implement them on a moment’s notice. The costs of mitigating these risks, such as keeping other contract personnel on standby, can be significant. 

Many project managers simply calculate the delta for vendor pay rates against in-house personnel costs. That often underestimates the financial and risk impacts on their organization. Be sure to evaluate all these possibilities in hiring a contractor to produce more accurate project costs and risks.

Have a vendor challenge or success tip for the rest of us? Share in the comments section.

For more about vendor management, check out Oliver Yarbrough’s Project Management Foundations: Procurement course.

 

Coming Up

My course Project Management Foundations has been updated with several text-based entries in the Table of Contents. You can read up on the hybrid project management lifecycle, get tips on creating a project information system, review a checklist for effective meetings, and more.

 

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 90,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

Dear Bonnie,

I’m a project manager and I was sitting in the office common area when my colleagues launched an energetic debate about which was better, product management or project management. I tend to prefer the word different instead of better, but my colleagues wouldn’t budge. Can you give some guidance on this?

Thanks,

Better, Worse, Different, or?

 

Dear Better, Worse, Different or?

My first few thoughts: 1. Avoid the office common area and take a walk outside even if the tornado warning sirens are going off. 2. Your colleagues should find better topics to argue about. My college dormmates would brainstorm physics for increasing the hours in a day so we could finish our assignments. But I digress.

Sadly, you have stumbled onto the unavoidable office pastime: people loudly debating things they barely understand. In this case, arguing which one is better than the other is like arguing over whether your lungs breathing or your heart beating is better. Try having only one and let me know how that works out.

Product management and project management are two totally different occupations working toward the same goal: making something useful actually happen.

Let me try to break it down into terms your colleagues might grasp.

Product managers are people who sit around and say things like, “You know what the market is missing? An egg yolk and white sold pre-separated in an egg-shaped single-use plastic container for people who can’t take the trauma of cracking an egg.” They study marketplace trends, identify user needs, develop novel ideas, analyze competitors, and build the product lifecycle (how and where it will be built, who will sell it, and how it will be supported once it hits the market.)

Meanwhile, Project managers take that well-being enhancing fever dream with requirements that product management produces and create a plan for bringing the product to fruition (from research, design, development, construction of the manufacturing line, testing, and product validation). They assess risks like the plastic shell breaking when customers try to open the container causing a completely different type of trauma. With plan in hand, they evenly reply to the product managers, “Dope, dude. Here’s the budget, timeline, resources, risk log, and a pilot launch feasible for Q3.”

When the project is done, the project managers turn the product and its manufacturing line over to the product managers, who will work their marketing magic and support the product on an ongoing basis. (At this time, the project manager might get kudos and the opportunity to work on fulfilling the next wild product idea.)

Your instinct to say “different” is spot on. Because anyone with better things to do knows product and project managers are on the same team. Product managers ask, “Should we build this?” Project managers answer, “Here’s how we build this without blowing up the company, or worse, our customers.”

With warm yet different regards,
Bonnie

If you have a burning question, add it to the comments section or send me a message on LinkedIn.

 

For more about product management, check out Rich Winnie’s Product Management First Steps course. The link for my Project Management Foundations course is below.

 

Coming Up

A day in the life of a project manager can seem like an endless parade of problems, which can turn almost anyone into a pessimist. Reframing problems into opportunities and a sincere search for solutions can significantly improve performance: yours, your team’s, and your projects’. Join Jason Mackenzie and me for Office Hours on Wednesday, May 7, 2025 at 9am MT, we’ll discuss how positive reframing can improve communication and results at all levels. Click here to join!

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 89,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

 

Dear Bonnie,

I have a problem with delivering on schedule. My technical team eventually gets their job done, but it takes them forever to complete anything. How can I light a fire under them so I can complete my projects more quickly, and more importantly, on time?

Signed, Is it done yet?

 

Dear Is it done yet,

Ah yes, the elusive on-time tech team—known to inhabit the wilds of your organization like a snuggle of sloths: adorable and clearly not in a rush. (I looked it up. That cute curled up pile of sloths is called a snuggle.)

Let’s start with a revolutionary concept: maybe they aren’t a snuggle but, rather, a scurry of squirrels (yup, checked that one too) doing other stuff. You’re teed off that your project is moving slower than a sloth on a NyQuil drip, while they could be buried by higher priority acorns that someone (probably with more clout and an intimidating glare) told them to finish first. Try asking them nicely what’s going on and, even better, if there’s anything you can do to clear their path. Bribing them with nutty snacks can’t hurt.

Next, remember that tech teams are usually zip-tying the entire infrastructure together while fending off the latest “urgent” request from someone who yells and also thinks their mouse is a dysfunctional laser pointer. If your project is languishing on the “once the network stops crashing” list, you have two options: yell louder than the others (not recommended) or consider hiring a contractor whose job it is to care about your project because you’re paying them to.

And finally, the nuclear option: sponsors. You know, the people who can send a single email, which prompts the team to act like they’re in a Red Bull commercial. If your project has real value (at least in your opinion), get your sponsor involved. Nothing lights a fire under a slothful tech team like a VP breathing down their neck like a caffeinated Komodo dragon. If your team is scurrying, you can earn their everlasting loyalty by coaxing your sponsor to protect your team’s time and sanity like a mama bear warding off unreasonably demanding stakeholders.

Good luck! If all else fails, you can say that the delays are part of your “iterative process.”

Cheers,

Bonnie

I sincerely apologize to any species I’ve offended by omitting them from the metaphors in this article.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 89,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________