When To Deviate from Project Methodology

/in /by

Following a project methodology ensures that your project team, customers, and sponsor know what to expect and makes the project team’s efforts predictable. However, there are times when diverging from your methodology may be the best thing to do to ensure project success.

  • Unexpected challenges occur. When market conditions or technological disruptions change suddenly, the methodology might decrease your team’s ability to respond. For example, a competitor releases an update to their product earlier than expected, and it’s better than your organization’s product. Expediting a project to stay competitive could be more important than methodology. For example, could the project team switch to agile practices even if the original plan was waterfall-based? Or you might consider shortening deliverable review periods and other time savers.
  • Constraints impact the project. Tight budgets or limited personnel might require a shift away from methodologies that require specific resources or timelines. Simplifying processes or adopting lean principles could be more effective in these situations. By eliminating non-essential tasks to focus on what’s essential, the project might progress despite constraints. Note: Reevaluate the risks associated with eliminated activities to make sure the project’s risk level is still acceptable before you proceed.
  • Team dynamics make the methodology cumbersome. The dynamics of the project team can influence a methodology’s effectiveness. If the team thrives on spontaneity and creativity, a rigid structure may stifle innovation. For example, asking a team in research and development (R&D) to follow the same methodology as other project teams could be counterproductive. That’s because R&D work needs more flexibility and creative problem-solving approaches to deliver better project results.
  • Partnerships are involved. When a project involves novel solutions requiring extensive collaboration with an external organization, deviation from the standard methodology may be needed. First, the partner organization may use a different project methodology because of the products they create. Second, the teams may be concerned about confidentiality that the methodology would expose, such as sharing test data. (Test data often derives from customer production data, which might reveal information that shouldn’t be shared.) 

Consider carefully before you make a decision like this. Do you have a valid reason to make this change? Don’t make it unilaterally. Talk to your teammates and management first.

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

Coming Up

Office Hours Live – What’s wrong with project management these days? October 3, 2024  5PM MT Several aspects of project management don’t get much attention from management, project managers, and project teams. In turn, project management software sometimes ignores those areas as well. Bob McGannon and Bonnie Biafore will discuss these topics, so you don’t skip important duties. And they will talk about what to do if your software doesn’t cover them. Topics include: The 40-hour work breakdown rule (myth?) Estimating Cost management Project management versus work management Choosing the correct project management methodology Scheduling in waterfall and iterative projects Prioritizing project work versus operational work. To sign up, here

Office Hours Live – Learning Microsoft Project: Ask Me Anything October 8, 2024 1PM MT 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 77,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.

_______________________________________

Key Qualitative Values in Project Management

/in /by

The Project Management Institute (PMI) defines value as “the worth, importance, or usefulness of something.” To stakeholders, usefulness is more than quantitative measures of how deliverables satisfy a business case. Qualitative value comes in many forms. Here are several key qualitative values to consider for your projects. 

  • Deliverables must work with existing processes. Project deliverables might work well in isolation, but things can get awkward when deliverables need to work with current business processes. Qualitative value can be the consistency of data formatting, how it’s passed from process to process, how it’s displayed onscreen, or how a new deliverable facilitates decision-making. A new business process should be easy to understand and use not only by people whose job focuses on only that business process, but also by other users who focus on the bigger picture, like end-to-end cash flow, which spans multiple processes.
  • Using deliverables should be intuitive. Deliverables should be easy to use and provide a seamless customer experience. This includes intuitive design, ease of navigation, and accessibility, which all contribute to the overall user experience. A significant indicator of intuitiveness is the time and effort it takes to train project customers to use the deliverable. Early versions of a deliverable should be shared with customers, while the team documents any questions the customers ask as they learn to use the deliverable. These questions can guide how to improve the deliverable and increase its intuitive nature.
  • Deliverables, particularly physical deliverables, should generate an emotional connection. With a physical deliverable that customers use, a deliverable that resonates emotionally can increase its success. For example, the value of clothing and toys increases dramatically when they generate emotion. The desire to use a product and feeling good when doing so makes the difference between moderate and exemplary success. This emotional connection can be developed through storytelling, brand values, the ability to join or create a trend, and comfort.
  • The deliverable has aesthetic appeal. A deliverable’s visuals and aesthetics can enhance its value. A computer system with easy-to-use screens that are also attractive generates greater value. A well-designed product that is visually appealing also attracts customers and improves overall satisfaction. Imagine standing in front of a mirror with new clothes and thinking, “I’m looking good!” Aesthetics, alongside usability and comfort, offers significant qualitative value.
  • Customization. Deliverables that offer customization or personalization options provide significant value to customers. This allows project stakeholders to tailor the product or service to their needs and preferences, increasing its relevance and utility. For example, in mobile phones, the ability to add, delete and arrange icons allows these devices to suit individual needs. The perceived value of a mobile phone would significantly diminish if everyone was stuck with the same set of icons and settings.

Think about a deliverable from your current (or a previous) project. Create lists for how the deliverable might provide value both quantitatively and qualitatively. Can you think of other factors beyond the above list that increase qualitative value? How would you determine whether the deliverable successfully produces that value?

Coming Up

Office Hours Live – October 3, 2024  5PM MT –  What’s wrong with project management these days?

Several aspects of project management don’t get much attention from management, project managers, and project teams. In turn, project management software sometimes ignores those areas as well. Bob McGannon and Bonnie Biafore will discuss these topics, so you don’t skip important duties. And they will talk about what to do if your software doesn’t cover them. Topics include: The 40-hour work breakdown rule (myth?) Estimating Cost management Project management versus work management Choosing the correct project management methodology Scheduling in waterfall and iterative projects Prioritizing project work versus operational work. To sign up, here

Office Hours Live – October 8, 2024 1PM MT –  Learning Microsoft Project: Ask Me Anything

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 77,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.

_______________________________________

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.

_______________________________________