Archive for month: May, 2025

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.

_______________________________________