Posts

Skills and Knowledge that Agile Team Members Need

/in /by

Agile projects rely on different skills than those of traditional waterfall projects. The required skills vary based on team members’ roles. Here are vital skills and knowledge the people on your agile team need. 

  • Communication, especially listening skills. Agile involves the constant exchange and implementation of ideas. As a result, agile team members need refined communication skills. Balancing business needs with technical constraints is important so the team can manage the product backlog. Specifically, the product owner must be able to discuss overall business processes and the implications of process changes needed for accommodating technical tool improvements. The SCRUM master must have good coaching and facilitation skills. At the same time, testers and designers must be able to listen to and translate requirements and user preferences so that designs and implementations meet project goals.
  • Breadth of knowledge about the business. Beyond business processes, the agile team must understand the implications of their solutions to the business as a whole. For example, improving processes for the finance organization might change procedures for marketing, sales, and manufacturing. In this case, it’s crucial to ensure the changes the agile team makes for the finance organization don’t negatively impact other business functions. So, the product owner and other business representatives on the team need a broad understanding of procedures and policies across the business. Of course, this knowledge is essential for all projects, but agile’s focus on speed of implementation requires this knowledge to be embedded in the team itself rather than verified through others.
  • Breadth of technical knowledge. Agile projects often create standalone applications that can be built quickly. This requires knowledge of current tools, coding practices, and the data stores from which information is extracted. With legacy systems, to ensure technical and business processes aren’t inadvertently altered , teams need in-depth knowledge of those systems, as well as the states of data as it passes through the systems. For example, suppose you extract profit information from existing systems. In that case, you need to know where to get the specific profit state data you want (like before taxes, after taxes, or other versions of profit) in the databases. The agile team must know this to avoid delays arising from quality assurance issues.
  • Creative (and in-the-moment) problem-solving skills. One of the benefits of agile is…..it’s agility! Although the project’s intent is understood, how that intent will be satisfied isn’t always known. Customers learn as features are produced, which means what they ask for can and will change during the project. Those changes can present problems to solve, often quite spontaneously! As a result, all team members need keen problem-solving skills, because new requirements can mean challenges for business team members, technical team members, or both! 

What other skills do you think are needed from agile team members? Share with us in the comments section.

For more about agile projects, check out Doug Rose’s Agile Foundations course.

Coming Up

My updated version of Learning Microsoft Project is now available in the LinkedIn Learning library. To celebrate, I’m holding an Ask Me Anything (AMA) Office Hours on October 8, 2024, at 1pm MT. Whether you take this updated course now or you’re an experienced Project user, this hour is for getting answers to questions you have about MS Project. (If there is a wild outpouring of questions, I will host another event in November.) To sign up, click here.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 76,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.

_______________________________________

As Agile as Possible: Advanced Techniques for Agile Project Success

/in /by

Agility goes beyond the basic principles of Scrum and Kanban. To excel with Agile, teams must adopt behaviors and techniques that enhance flexibility, collaboration, and responsiveness. Here are strategies to improve the success of Agile projects: 

  • Allow extra time for learning. Resist the temptation to rush to the next sprint. Give your agile team some time to learn from each iteration and adapt. Support team members’ ability to regularly review their processes and outcomes, identify areas for improvement, and implement changes. Doing so provides benefits like increased efficiency, innovation, and creativity.
  • Expand stakeholder feedback processes. Actively engage in processes to collect and incorporate feedback from stakeholders outside the agile team. Go beyond only end-of-sprint reviews. Initiate ongoing dialogue with customers to ensure deliverables evolve with stakeholder expectations. Not only does this create better products, but it minimizes end-user-related risks and ensures that deliverables align with business objectives.
  • Implement collaboration tools (even if you feel they aren’t necessary). Many good collaboration tools on the market facilitate seamless communication and coordination among team members. These help both co-located and virtual teams. Tools that support real-time updates, integrated task management, and virtual meetings can significantly improve the team’s ability to work cohesively and respond to changes quickly. They also provide easy-to-understand status information for all stakeholders. Check the comments section for several popular collaboration tools.
  • Increase the use of cross-functional team members. The heart of agile methodologies is expanding capabilities and freedom of thought for team members. The broader the skills and experiences those team members possess, the more contributions they make to the project. Look to expand your agile teams with as wide a reach as possible. This reduces dependencies on external teams and accelerates problem-solving. Also, this allows team members to broaden their skill sets and business knowledge to take on multiple roles in future projects. 
  • Use a broad set of senior stakeholders to prioritize the backlog. Considering many viewpoints in prioritization ensures the highest-value features are delivered first. Also, don’t skip scheduled re-evaluations of the product backlog. Thar way, the team will always be tackling features that significantly impact tactical and strategic goals.

If you’re working on agile projects, evaluate how your environment handles these strategies. Can you spot ways to improve?

For more about agile strategies, check out Doug Rose’s Agile Foundations course.

Coming Up

My updated version of Learning Microsoft Project is now available in the LinkedIn Learning library. To celebrate, I’m holding an Ask Me Anything (AMA) Office Hours on October 8, 2024, at 1pm MT. Whether you take this updated course now or you’re an experienced Project user, this hour is for getting answers to questions you have about MS Project. (If there is a wild outpouring of questions, I will host another event in November.) To sign up, click here.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 76,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.

_______________________________________

Dealing with a Micro-Managing Customer

/in /by

I was recently asked how to deal with a micro-managing customer, especially when the sponsor isn’t standing up to them. Here are a few tips for handling this challenge whether you’re a project manager or team member.

  • Trigger a debate. A stakeholder might micro-manage the project team when they feel that’s the only way to get what they need. They press their needs upon the project team without consideration for other areas of the business. In that situation, call a meeting with key stakeholders to debate the prioritization of project requirements. If other stakeholders choose not to defend their needs, the project can proceed with the micromanager’s priorities. Note: The project manager’s responsibility is to point out when a prioritization imbalance might exist. It is not to decide prioritization on behalf of the business. So, even if stakeholders are being passive, follow the outcome of any prioritization meeting where the key stakeholders are present.
  • Understand the micro-manager’s fears. Micro-management has a root cause. In addition to a perceived need for prioritized requirements, that cause could be past project failures or bad experiences with delegation. Micro-management might also be considered a way to circumvent organizational politics regarding the project.  Identifying the fear that created the micro-management helps you negotiate processes for a more productive relationship. Be understanding and flexible, and you might be able to reduce the level of micro-management.
  • Follow the money. In many organizations, the stakeholder who provides funding is the “final arbiter” for project scope and requirements. If the funding provider is neither the passive or micro-managing stakeholder, brief the funding stakeholder about the micromanager’s behavior. Understand the funding stakeholder’s priorities. If they don’t align with your micro-managing stakeholder’s priorities, tell the micromanager that you’re following the funding provider’s direction. If they protest, tell them to talk to the funding stakeholder and alert the sponsor as well.
  • Point out any conflicting directions and stop the project. As a project manager, if you receive inconsistent or conflicting direction, even after trying to trigger proper debates, you have only one viable recourse. Stop the project. This might seem risky. But moving forward while stakeholder conflicts are outstanding is irresponsible and conflicts with the ethical standards promoted by the Project Management Institute and other industry bodies. Stopping the project is proactive and less expensive than going forward with unresolved issues. So, stop working, document the conflicting directions you have received, and share them with the stakeholders in conflict. Only move the project forward after a debate is complete and the direction for the project is aligned.
  • If you are a team member… Focus on the information the micro-manager shares when they give you direction. That way, you can get insight to their motivations. Ask them questions about what they are trying to accomplish and what they are concerned about. Look for trends or patterns in the direction they give you. With this background, you might be able to anticipate future requests and proactively predict the bigger picture of what they are trying to achieve. That can help you establish trust and reduce their micro-management.
  • Running an agile project? Embrace the involvement! Agile works best when you customers are heavily involved. If a customer micro-manages, follow the agile spirit to address it. Call a meeting, talk as a team about what is and is not working with your customer, and strive to improve. Consistent and successful feature delivery will probably calm your micro-managing customer.

Have any experience with a micromanager? Share with us in the comments section. 

Coming Up

Check out my updated Learning Microsoft Project course! My updated version of Learning Microsoft Project teaches the absolute basics of Microsoft Project desktop in just over an hour. This revision includes more exercises to practice what you learn as well as a quick intro to Microsoft’s AI features for project management.

Also, I’m holding an Ask Me Anything Office Hours in October to answer your Project questions. Check my LinkedIn feed for a post about that event.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 75,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.

_______________________________________

The Project Goal is NOT to Complete Tasks!

/in /by

It’s important to remember that completing the project Gantt chart tasks or agile backlog items is not the ultimate project goal. Here are the true objectives project managers and their teams must achieve for successful projects.

  • Build capable stakeholders. All products or services a project provides should be easy to use, fit for purpose, and work with existing business processes. Stakeholders should be educated so the transition to those new products or services runs smoothly. They should be able to use them without help, and, if needed, help should be easy to obtain. efficiently get help needed.
  • Be a catalyst for learning and improvement. Projects always provide learning opportunities, such as risks that arise or relationships to establish with new vendors. In addition, every project involves estimation. Enabling learning and improving estimation accuracy by capturing the necessary information are valuable objectives that should be incorporated into every project.
  • Achieve the business goals. Projects are launched with a specific business outcome in mind: to deliver business value! That value might not be measurable immediately upon project completion. In fact, it could take several months to realize value. Project managers should consider their projects a success only when that value is achieved and recognized by stakeholders. Note: Establishing targets and processes to measure success should be part of every project!
  • Set the table for future projects. Projects are rarely standalone endeavors. They are part of a series of improvement steps or pieces of a long-term strategy to change a business. The completion of every project should facilitate the launch of future projects to expand the benefits delivered to the business. 

Think through the activities you perform as a project manager. Does your approach to project management help achieve these objectives? If not, what steps can you take to include them?

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

Coming Up

Be on the lookout for the updated version of my course, Learning Microsoft Project. Get up to speed quickly with Microsoft Project. Learn just the essentials you need to know to create projects, add tasks, assign resources, and run reports.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 74,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.

_______________________________________

Be on the lookout for the updated version of my course, Learning Microsoft Project. Get up to speed quickly with Microsoft Project. Learn just the essentials you need to know to create projects, add tasks, assign resources, and run reports.

Coming Back Strong from Project Failure

/in /by

Failed projects damage financial status, discourage creativity and growth, bruise egos, and set back careers. Good news: with time, failure can lead to positive outcomes. Here are some benefits that come from project failure.

  • Learning opportunities. Say an organization spends time and money upgrading an information system, only to have it shut down before producing usable deliverables. The organization learned two significant lessons from internal and external reviews. First, some people didn’t understand what the new IT system would do and how it would do it. Second, diligence in evaluating the business case fell short. No one researched whether project cost and staffing estimates were realistic before funding the project. Based on these findings, the organization changed some behaviors, which lead to better management on future projects.
  • Better process discipline. The organization’s project failure also highlighted teams not adhering to good business practices. The business case issue triggered additional reviews, which identified the same problem in other areas. Tthe organization made sweeping changes to increase process discipline, which improved the integrity of initiatives and results delivered to customers and shareholders.
  • Enhanced listening. Under business pressure, project sponsors can become overly optimistic and desperate to deliver outcomes. As a result, they might not listen to concerns being raised by staff members. Failures can prompt sponsors and stakeholders to reflect on team members’ concerns and give them more weight in future project decisions.
  • More effective handling of assumptions. Assumptions are part of every project. How long they remain assumptions makes a difference in project success. For the best results, assumptions should be evaluated early in the project lifecycle to determine whether they are accurate. When assumptions aren’t accurate, you make them the basis for robust risk management plans, which improve project success.
  • More team synergy and determination. After a failure, demoralized project teams can be invigorated when they hear about process changes they can implement to be successful and get support from senior managers.  People don’t want to be associated with failure. When they are, the best way to rebuild team morale and synergy is having a chance for redemption. That desire for redemption creates a lot of latent energy toward making a project successful.

Think about the last time you experienced project failure. How did your organization react and was it effective? Do you think the approaches described above would improve results in future projects?

For more about learning from project failure, check out Todd Dewett’s Learning from Failure course.

Coming Up

Be on the lookout for the updated version of my course, Learning Microsoft Project. Get up to speed quickly with Microsoft Project. Learn just the essentials you need to know to create projects, add tasks, assign resources, and run reports.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 74,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.

_______________________________________

Exercising Authority Appropriately

/in /by

The best project managers are stewards of the businesses they support. Part of caring stewardship is appropriately applying the project management authority conveyed by the project charter. Here are tips for ensuring you properly exercise your project management authority.   

  • Use positive influence. Exercising authority can take many forms: forming partnerships or collaborating to accomplish tasks, or less positive approaches like coercion and other forceful methods. Coercion is not the answer. Use your authority to build relationships with stakeholders to achieve project goals within the current business context. Consider project objectives in relation to other initiatives and operational constraints. Here’s an example: Encourage a stakeholder to resolve a vital customer issue even if it means delivering a task late (as long as the delay won’t hurt the business as much as a disgruntled customer).
  • Exercise your authority within the constraints of the project charter and your role – and no more. Going beyond those bounds, via direct or implied statements, might not cause problems immediately. Over time, however, stakeholders may question your leadership. This is especially true if you report directly to high-level managers. There is a risk that employees will assume what you say is coming from your senior manager. If used indiscreetly, this “referent authority” can dilute the respect you receive from stakeholders.
  • Lead the project with compassion. Leading a project with compassion means maintaining balance with sometimes conflicting elements. You have to balance your care and concern for people, the project, the business, and yourself. If you focus on project goals without taking care of your people, achieving project objectives will be at risk. Being too accommodating with people’s concerns at the expense of project objectives also causes problems. The key is to be flexible while seeking the best overall solutions to all concerns.
  • Enforce the boundaries of project scope. In some organizations, scope creep can reach pandemic proportions. Even a little bit of scope creep can negatively impact project success. To protect project scope, put all changes through a rigorous change review process. Don’t accept a change request unless there is a positive evaluation of the resulting scope, cost, schedule (as well as quality and changes in project complexity).  
  • Provide the leadership stakeholders require. No more, no less. For example, giving task owners the flexibility to complete their work is appropriate. But if deliverables are unacceptable, you must take action to correct that issue. On the other hand, micromanaging (too much “leadership”) isn’t effective either. Take time to learn how to constructively apply your authority and expertise with each stakeholder, understanding you will need to adjust your style to match the needs of each person. 

Take a minute to consider your authority as described in your project charter (or write up what you think your authority is if the charter hasn’t been prepared yet). Then evaluate your approaches and processes to see how you might need to adjust them.

For more about project authority and leadership, check out Cyndi Snyder-Dionisio’s Project leadership course.

Coming Up

Join Angela Wick and me on Tuesday, August 13, 2024 at 12:00pm MT for our live broadcast PMs and BAs: We need to talk…about AI…and how it’s impacting our roles!

Everyone’s talking about AI these days. But is anyone listening? The focus is usually on how AI can make people more productive. Productivity boils down to doing the same old stuff faster. Our teammates and stakeholders use AI too! We will explore the benefits of focusing on using AI to make our deliverables more valuable to the people we work with and also how our roles impact our stakeholders who use AI!

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 74,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.

_______________________________________

What PM tools tell us about today’s project management

/in /by

Research for the update to my course on choosing the right project management tool was enlightening: it offers an interesting perspective on what’s happening in project management today. 

  • Collaboration and communication are the focus. Today’s automated tools place significant emphasis on communication and team synergy. Tools can tag team members, integrate with email systems to alert people to upcoming tasks and status changes, and provide links to reports. This is a promising indicator for project management with communication always at the heart of successful project delivery. And this trend is perhaps due to more people work remotely or on hybrid remote/on-site hours.
  • There is power in visibility. Graphical representations of project status, task status, and work queued up for team members are visible to all. This transparency helps management and team members respond early to project issues and backlogs, improving overall project delivery and helping balance workload across team members.
  • Agile is the go-to approach. Agile methods are suited to businesses’ expectations for speed and developing solutions collaboratively. The benefits and popularity of agile are easy to see in the project management tool market. Compared with four years ago when the initial PM tool comparison course came out, project management tools almost unanimously embrace agile principles and deliver Kanban and Scrum capabilities.
  • Scheduling isn’t where it needs to be. While agile is dominant, not all projects are suitable for agile methods. My recent research shows little progress in managing traditional waterfall schedules. Gantt charts are commonplace, but the logic for predecessor-successor dependencies is often lacking along with the absence of displaying critical path and managing baselines. These features are available in well-established PM tools like Microsoft Project Online and Primavera. For other tools, do your research if you require Waterfall-style schedule management. 
  • Cost tracking isn’t mainstream! The most surprising thing from the research is that cost management is rarely included as a basic feature. Some tools offer ways to add a fixed cost or a cost forecast to tasks. Seldom do you find the ability to estimate effort, enter an hourly cost rate per team member, and track the time team members spend on tasks. As a result, cost management is essentially a manual effort involving optional features or product integrations.

If you’re searching for a project management tool for your organization, keep an eye out for my updated course on PM tools.

Coming Up
Join Angela Wick and me on Tuesday, August 13, 2024 at 12:00pm MT for our live broadcast PMs and BAs: We need to talk…about AI…and how it’s impacting our roles!

Everyone’s talking about AI these days. But is anyone listening? The focus is usually on how AI can make people more productive. Productivity boils down to doing the same old stuff faster. Our teammates and stakeholders use AI too! We will explore the benefits of focusing on using AI to make our deliverables more valuable to the people we work with and also how our roles impact our stakeholders who use AI!

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 74,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.

_______________________________________

The Value of a Project Manager’s Perspectives

/in /by

Success managing projects relies on accurate and timely information, which is needed by both the project manager and the sponsor. Project managers bring unique perspectives that sponsors and other senior stakeholders often lack. Be sure to share these perspectives with the management team, underscoring their role in the project’s success.

  • How workload volume affects operational teams. Projects are rarely delivered by team members dedicated to the project. Team members from operational areas serve important roles in most projects. These project assignments can create challenges for operational department managers and their key personnel. Project managers need to understand those challenges and schedule assignments to minimize the impact on the operational team. Project managers can add workload risks to project plans. To achieve the best balance between operational and project work, project managers can communicate the challenges to senior leaders and recommend how to prioritize project and operational work to best serve the business and the project.
  • How competing workloads interfere with project progress. Managers often launch projects and operational initiatives without recognizing how those efforts might conflict. Some conflicts stem from pulling a critical project resource to handle operational matters. Senior leaders need to be aware of these resource conflicts and decide on prioritization for the organization’s best interest. Project managers often have the clearest view of these resource prioritization issues and can make recommendations to senior leaders, so project delivery expectations are realistic.
  • The state of team morale. Senior leaders typically deal with their management colleagues and high-level customers. Project managers interact with first-level managers and team members. As a result, they have a view of the dynamics and attitudes of the organization’s rank-and-file population that they can share with senior leaders to head off serious morale issues that can hurt project performance.
  • Insight into levels of collaboration. Pressures and expectations on departments in an organization can affect the degree of collaboration within a project team. These expectations can come from management direction and sometimes, from perceptions that don’t align with management expectations. Project managers can investigate the source of reduced collaboration and share this with management, who can take action to motivate department members to collaborate more.
  • How management can support organizational change. Consider this story: An organization prides itself on its face-to-face interaction with its customers. A project is launched to create an automated self-service model for customers to obtain some services. Reasonable project and objectives. However, the project would challenge a deeply-held element of the organization’s culture, the one-on-one interaction with customers. The senior leaders think all is well, because they communicated the project’s intent. The project manager might perceive that employees wonder whether this is the start of erosion of the organization’s culture of personal interaction with customers. This insight is vital for senior leaders to know. The PM can communicate the insight to the senior leaders. The PM can also suggest that the senior leaders communicate and reassure the team that the organization will continue to embrace a face-to-face culture. This would help ensure that the project is a success, and that the organization embraces the self-service model for customers (if they wish to) to interact with the organization.

Take a moment to think about the projects you’ve managed. Have you ever seen things that the senior leaders missed? How would you present your perceptions now to help executives see their value?

Coming Up

I am busy updating two of my courses. Later in the year, you’ll be seeing new and improved versions of Learning Microsoft Project and Project Management Foundations: Choosing the Right Online Tool. The latter course will review more tools than the original using a different format.

______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 73,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.

_______________________________________

When to Defer Decision-Making

/in /by

Timely decision-making is a valuable skill for project managers. There are times when deferring a decision is the best way to respond to project situations. Here are some situations when delaying a decision make sense.

  • Your vendor has product upgrade plans. What if the release date for an updated product isn’t finalized yet? Rather than sticking with the current version or gambling on the new one, set the software decision as late as possible in your plan. When your decision time arrives, you can evaluate up-to-date information about the release to decide on what to do.
  • Stakeholders are debating the project’s value. It’s risky (and perhaps costly) to continue when key stakeholders are debating the value of your project or a part of it. can be risky — even if deadlines are looming. Continuing might alienate a stakeholder, leading them to withdraw their support. Wait until the stakeholders’ debate is over before making your decision. If deadline pressure becomes overwhelming, work with your sponsor to expedite the stakeholder’s discussion.
  • Regulatory changes are under consideration. With regulated outcomes, project solutions must conform to legislation. Regulations might apply to the methods for creating outcomes, like the highly-legislated process for testing new drugs. If regulations are under debate or are being revised by government agencies, wait until the changes are confirmed before deciding on how to produce project deliverables. Note: Speed to market that conforms with new regulation can be a valuable business strategy. So you might decide to speculate on the implementation of a regulatory change and move forward with a solution  — or produce multiple deliverables to accommodate regulatory options. Even in this case, wait as late as possible to understand the potential regulatory changes.
  • Cross-project dependencies are delayed. When deliverables from another project are prerequisites to your project and they are late, you might have to delay decisions in the successor project. Be sure you understand the prerequisite’s makeup and outcome before making a decision about how to use the full capabilities of that deliverable. As with regulatory changes, you might speculate about the deliverable, but you should wait on that so you know as much as possible about the deliverable.
  • Resource availability is unclear or undetermined. An appropriate level of technical and business process expertise is important on project teams. It can be beneficial to wait to see if the management team can make a knowledgeable staff member available. If that expertise isn’t available, you’ll have to hire skilled contractors or allow more time for lesser-skilled people to get up to speed and perform work. These options cost time and money, often much more than you’d spend on that expert staff member.
  • Stakeholder requirements are unconfirmed or delayed. Project failures can be caused by project teams designing and producing deliverables without getting accurate requirements from stakeholders. They move forward assuming they know what stakeholders want. This alienates stakeholders and reduces their confidence in project deliverables. That could result in deliverables being partially implemented or not at all. Bottom line: wait until key stakeholders confirm the project deliverables before moving forward.

If you have a decision coming up, think about whether there is an advantage to delaying it. If you can think of other times when a delay is beneficial, share them with us in the comments section.

For more about decision-making, check out Becky Saltzman’s Critical Thinking for Better Judgment and Decision-Making course.

Coming Up

I am busy updating two of my courses. Later in the year, you’ll be seeing new and improved versions of Learning Microsoft Project and Project Management Foundations: Choosing the Right Online Tool. The latter course will review more tools than the original using a different format.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 73,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.

_______________________________________

Beyond SMART Requirements

/in /by

Making sure business requirements are suitable is a valuable practice. Using SMART requirements (Specific, Measurable, Achievable, Relevant, and Time-bound) is a great start, but it isn’t always enough. Here are other requirement characteristics that help keep projects out of trouble.

  • Will the requirement cause conflict? Requirements can benefit one part of the business and cause difficulties for another. For example, creating a streamlined approach for selling a product might help sales while creating problems for the finance department in collecting client payments. Identify potential conflicts and try to adjust requirements to benefit all business areas.
  • Prioritize the requirements. Prioritizing requirements accomplishes two important things. First, in the event of budget cuts, you can remove requirements that have the least impact on the delivered solution. This strategic approach to prioritization simplifies scope management. Second, the discussions around prioritizing requirements are an educational process for the project team. The more the team understands stakeholders’ needs and business rationale, the more effective the project deliverables can be.
  • Are stated requirements “the tip of the iceberg.” Stakeholders sometimes think about their immediate needs and overlook the big picture. For example, a sales team presents a requirement to enable customers to select product color on the company website rather than talking to a sales agent. This could trigger an avalanche of requests for choosing different product options via the web. In this situation, the project team might proactively ask whether product options beyond color are desirable. That way, the development team could design and build a more comprehensive set of product options, which might be cheaper and more efficient in the long run.
  • Does this requirement impact regulatory processes? Businesses consider process or tool enhancements to increase productivity. What if enhancements affect outcomes that are needed by regulatory requirements. The process to create a regulated outcome might also be regulated. Make sure requirements don’t violate regulatory standards for processes and outcomes.
  • Are test cases available and feasible to create? Complex projects can involve multi-faceted requirements. Test cases assess a solution help determine whether the project solution satisfies a requirement. There’s a risk when test cases can’t be derived or are extremely expensive. The next logical step is to assess that risk to determine if you should accept the requirement. Commercial Off the Shelf Software (COTS) provides an example. Some COTS components are not validated via test cases because non-functional requirements, like usability or real-world performance, might not be adequately testable during development (due to lack of access to client production environments and so on).

Add these characteristics to your requirements checklist. If you have other items on your checklist, share them with us in the comments section.

For more about requirements, check out Angela Wick’s Requirements Elicitation and Analysis course.

Coming Up

I am busy updating two of my courses. Later in the year, you’ll be seeing new and improved versions of Learning Microsoft Project and Project Management Foundations: Choosing the Right Online Tool. The latter course will review more tools than the original using a different format.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 72,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.

_______________________________________