Avoiding Traps in Technical Project

/in /by

Projects involving technology are challenging for project managers. But it’s rarely the technology that presents the challenges. Here are ways to avoid common traps that trip up PMs leading projects with technical components.

  • Projects are really about business processes. Projects to deploy technology typically produce two things: increased productivity and/or reduced cost. What delivers these outcomes is improved business processes. These process changes must be acceptable and learnable by business staff. There is often more than one technical tool that can produce these business process improvements. Many projects get stuck by choosing the technical tool first. That forces the team to try to fit the business process to the tool, which can be tricky. So, don’t  consider the new technology as the output of the project. It’s the enhanced business processes that generate results.

  • Support project and organizational change management. No change is too small to deserve attention. Technical changes may seem trivial to team members used to dealing with IT or engineering tools. As a result, they don’t realize the stress new tools can bring to business stakeholders. Experienced project managers support both project and organizational change management. This helps ensure the integrity of the project deliverables, testing regime, and product documentation. As you develop your project schedules, make sure to include specific tasks to help bring your stakeholders along on the change journey. This will ensure project stakeholders are aware, trained, and ready to incorporate new tools and processes into their work practices. Only then will business value be realized.

  • Ensure new technical functions are useful. New technical capabilities can enhance business productivity…or not! Organizations often become enamored with installing the latest version of a tool to get the latest functionality. New technology isn’t always helpful. Think about how new functionality can fit into your business processes. If opportunities exist, take advantage of them. If new functionality doesn’t help enhance business processes, why install the latest version? Note: One benefit to updating technical tools is so they are supported by the vendor.

  • Control the pace of change. Make sure you don’t ask your business stakeholders to absorb too much change too quickly. This typically isn’t a concern with waterfall projects. These projects produce single large updates, which are scheduled well in advance. Pace of change issues occur only when many waterfall projects finish around the same time. Agile projects can lead to pace of change issues, because they release small deliverables quickly. While speed of delivery is usually helpful, too much change can decrease the value the business realizes from project outcomes. Look at the overall schedule for changes the business must handle to make sure the pace is manageable.

  • Run “business projects with technical components,” not “technical projects.” The vast majority of “technical projects” are meant to deliver business value. So, they should be driven by business stakeholders who collaborate with the technical team. This way, the business is responsible for delivering requirements and assessing business risk. Many technical teams believe they would do this better, because they understand how the technical tools work, including the business processes they support. This is risky though. Technical team members often don’t understand the nuances of delivering business outcomes. Also, buy-in from business stakeholders can be challenging when the technical team drives business improvement projects. Instead, keep the focus on the business objectives and business stakeholders.

Think about the last project you worked on that involved technology. It seems like they all do. How could you have applied these tips to make the project run more smoothly and deliver results more successfully?

For more about technical projects, check out Bob McGannon’s Project Management: Technical Project course.

_______________________________________

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

_______________________________________

Embracing an Agile Mindset

/in /by

Adopting agile methodologies successfully requires the right mindset. For this iterative and adaptive approach to thrive, you need to embrace the following elements and characteristics. 

  • Speed and experience. Agile produces outcomes quickly, but that speed comes at a cost. You need dedicated experienced people on the team to produce quality outcomes and you need management involved in the effort, so they know what they’re getting. Don’t try to have less experienced people produce interim deliverables, which are then reviewed by those with experience. If you do that, the experienced folks can find shortcomings in the deliverables and request changes. For agile to work, deliverables and decisions must be “veto-proof.” That is, they cannot be overridden by a team leader or manager who doesn’t like the outcome. This demoralizes the team and sacrifices the speed that agile is supposed to generate. 
  • An “allow for learning” mindset. A benefit of agile is that it allows stakeholders and team members to learn. Using deliverables inspires learning and continuous improvement of the project’s products. That means stakeholders must be ready for products to be reworked after installation. Also, that learning often shifts the priorities from producing new deliverables to reworking earlier ones. Overall, this volatility in what the team works on is productive. The downside is that stakeholders who are eager to use new features might be disappointed. To support the learning organization mindset, be sure to communicate and reassure stakeholders.
  • Encouraging frequent small improvements. Agile produces the most important, business-improving deliverables early. This fast delivery of value can create expectations that business improvement will continue at that rate. Yes, the improvement will continue, but not at the same blistering pace as at the project start. The outcomes that agile produces are typically incremental improvements. Rarely does agile produce single big leaps. Make sure stakeholders understand that improvements will be smaller and that changes will occur often as the project continues.  
  • Trust and empowerment. For an agile team to thrive, stakeholders, management, even end users, must trust the team. The team needs to have permission to decide how to accomplish business objectives. This includes making decisions about adjusting business processes.   If trust isn’t there, the value of agile diminishes. Speed decreases, and team members will become frustrated.  
  • Simplicity. Agile methodologies favor simplicity over complexity and excessive documentation. Simplicity applies to processes, communication, and deliverables. Stakeholders must forgo the bureaucracy and documentation they received in the past. Focus instead goes to delivering working solutions. Documentation is developed from an exercise of watching how end users use those working solutions.

Do you have other suggestions to add to the agile mindset? Share with us in the comments section.

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

_______________________________________

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

_______________________________________

Criteria for Accepting Deliverables

/in /by

What criteria do you use to accept a deliverable? Have you ever even thought about it? I recommend applying more scrutiny to whether a deliverable is complete when closing a task. Here are criteria for deciding whether to accept a deliverable and close project tasks.

  • Deliverables have been produced and can be reviewed. You can’t accept a deliverable if it doesn’t exist yet – or you don’t know that it’s ready. The deliverable for a completed task (software code, machine part, installed stovetop, etc.) has to be shared and then validated. If a deliverable product or service can’t be reviewed (maybe the software is complete, but the server is down), then the tasks to produce that deliverable have to be kept open until the review is completed.
  • Acceptance criteria are met. The next level criteria is that the deliverable passes the tests and meets the stakeholders expectations. (This is why it’s important to document acceptance criteria before work starts on tasks.) If stakeholders aren’t satisfied, a task needs to stay open or new tasks have to be added to your schedule to correct the deliverable, so it meets expectations.
  • Broad stakeholder approval is received. In some cases, deliverables need to be reviewed by other stakeholders after acceptance criteria are met, for example, customer reviews. The customers might not have provided acceptance criteria, but their views on the product’s viability are important. For this broader review, you distribute a sample of a product and collect customer opinions. If issues are raised, the related task(s) have to stay open or new tasks created to complete the work that needs to be done.

Sometimes deeper examination is called for before accepting a deliverable and closing project tasks. Consider the following techniques:

  • Does the product contain scope creep items? Scope creep usually occurs when a well-meaning stakeholder shares an idea with a well-meaning project team member. If that idea makes its way into a deliverable without going through the change management process, voilà, scope creep. If you find scope creep in a product, you should consider whether to accept a deliverable or ask your team member to remove the scope creep item and re-submit their product for review and task closure. For example, you might not accept the deliverable with scope creep until it has passed the change control process. Or you might decide that is the result of a broader interpretation of a requirement and does not have to go through change control. Some people might leave it in because “it seems to work,” but the rest of know that is an irresponsible thing to do.
  • Complete a detailed quality audit. At times, particularly in regulated industries, products aren’t considered viable until certified personnel have conducted a detailed review or audit, (medical instruments for example.) This activity usually goes above and beyond the acceptance criteria provided by internal stakeholders. When this audit is required, do not close tasks until the audit is complete and results are satisfactory.
  • Does the deliverable include appropriate documentation? If you don’t have a separate project task for creating product documentation, documentation needs to be delivered along with its corresponding deliverables before accepting the deliverable and closing the task.
  • Does the deliverables support successor tasks sufficiently? This acceptance criteria is often missing: whether the deliverable provides what successor tasks need. Don’t close a task until someone confirms that its deliverable allows successor tasks to proceed. 
  • Does the output create new risks? Sometimes, the approach taken to produce a deliverable is different than planned. As a result, downstream risks may arise, even though the product meets all the acceptance criteria.  In this case, consider whether to accept the deliverable. You might want to ask your team to use a different method that doesn’t create new risks.

What do you look at before you accept a deliverable?  Do have any best practices to add to this list? Share with us in the comments section.

_______________________________________

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

_______________________________________

Building the Best Possible Project Team

/in /by

We usually don’t get to pick all of our team members. When you can, focus on individuals’ characteristics that will, when combined, give you the best possible team. Here are five key traits for a successful project team. 

  • The ideal mix of skills. Every project team needs the proper mix of technical and business skills. That way, the team can produce the right products that are usable by the business. You need a team that can design and build a product, but can also perform business analysis to develop procedures that will optimize the use of that product, In addition, personal characteristics, such as patience, diligence and the ability to multi-task can be important. Think through the skills you need as you build your project scope statement. 
  • Include people with earlier experience working together. Team members that have worked well together before are more likely to succeed on future projects. Over time, working together means you have a better understanding of each other’s strengths, weaknesses, and working styles. This familiarity can lead to improved foresight, more effective communication and efficient problem solving. 
  • Include team members who directly benefit from the solution. Involving people who benefit from the project solution can give you significant insights into its potential business impact. It also cultivates a sense of ownership among the project team. Note: Verify that the perspectives of the beneficiary team member align with those of the broader beneficiary group. That way, you won’t overlook discrepancies in objectives from different areas of the business.
  • Choose team members with positive relationships with key stakeholders. Maintaining positive relationships with key stakeholders can be the difference between success and failure. Good relationships build trust, and trust leads to better listening and improved exchange of both good and bad news. Good relationships also help ensure buy-in. And buy-in is crucial for meeting project expectations. 
  • Strive for diverse backgrounds and communication styles. Diversity in a team can lead to innovative solutions and improved problem-solving. A team that includes a mix of communicators, creative thinkers, and individuals from diverse backgrounds draw upon a wider set of knowledge, skills, and approaches to support business needs.

As a project manager, what choices have you made that improved your team’s performance? As a project team member, what team characteristics led to positive project outcomes? Share with us in the comments section.

For more about project teams, check out Daniel Stanton’s Project Management Foundations: Teams course.

_______________________________________

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

_______________________________________