Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
5 Tactics for Risk Collaboration in Specialty Software Projects
Categories:
Risk Management
Categories: Risk Management
| Many organizations choose to implement specialty software products as a business solution. The benefits of doing so vary from filling critical gaps in a company's portfolio of solutions and services to enabling a quick response to new regulations, such as health and safety mandates. Never assume that because a solution is smaller in size, you can take a relaxed approach to risk management. With enterprise resource planning (ERP) solutions, success requires collaboration between the project manager and the software provider to manage risks. Here are some successful tactics for risk collaboration with specialty software providers: 1. Encourage leadership engagement. While it is rare to meet a company CEO, it is likely you will work with the CEO of a specialty software provider. Early in the project, create a deep level of engagement between the leadership teams. For example, connect someone from your leadership team with the head of product development. An early leadership engagement will create a quicker path to resolve any issues. 2. Gain high visibility during analysis and design phases. During the early phases of a project, a high level of visibility will help you to avoid costly errors in later phases. Early visibility also results in a quicker path to understanding the overall solution. For example, conduct design sessions at the specialty software provider's office. 3. Align methods and terminology. Invest effort early on in the project to harmonize methods, phases, deliverable formats and milestones. Agree on the terms for completing a project phase, as well as common terminology. For example, define the difference between a customization versus configuration. When you agree on these things early on, it's less likely any confusion or miscommunication will pop up. 4. Make site visits. Nothing is more effective than talking with a current customer about their experiences with a specialty software provider. These discussions create visibility to both best practices and challenges. Utilize this outside view to refine your project risk approach. 5. Don't underestimate contingency. Even if a specialty software provider is smaller than an ERP company, it will still have the same fundamental delivery risks. Using a straight percentage for contingency may not be sufficient. Discuss with the specialty software provider a special contingency allocation to manage risks. Do you have any tactics for risk collaboration? |
Work to Live or Live to Work?
| Working with multigenerational project teams has taught me that commitment is a common attribute for team members of every generation. But every team member approaches commitment in a different way. Different generations place different values on pursuing work-life balance. A strong work ethic is a characteristic of the older members of the project team, part of the silent generation. Members of this generation tend to want to work a reduced number of hours to be able to devote time to personal activities. Baby boomers, the generation referred to as workaholics, consider work a high priority and greatly value teamwork. In my opinion, they are focused on their achievements and are willing to work long hours to achieve project success. Generation X is good at controlling their time. This generation has a desire to control and set a career path, personal ambitions and work time. Generation Y is driven by a strong preference for work-life balance. Many Gen Yers look for jobs that provide them great personal fulfillment. In my opinion, one of our tasks as project managers is to find ways to shed the stress in our project team members' lives. Part of that is to better understand the work-life balance needs of team members from different generations. To bring a better work-life balance to any generation, define more accurate project schedules based on flexibility, telecommuting and time off. Tell us about actions you have adopted to meet project goals and still accommodate team members' work-life balance needs. |
Maintain Control in Lessons Learned
| In a traditional lessons learned session that is conducted face-to-face, project managers know each person who is present and his or her role on the project. But technology today affords us the luxury of being able to do many things online -- such as holding a lessons learned session. We can engage with people across the country or someone who may be sitting right next door. Regardless of where someone is located, we must maintain a cordial and professional manner when we interact online. When you have dispersed project teams -- and even sometimes otherwise -- getting people to stay focused and not be disrespectful to others in a lessons learned session is a challenge. To overcome this, set the rules for participating in the session. Make sure participants understand them and agree to them. These rules should include:
When you maintain control of the meeting and employ general courtesy, it keeps the discussion flowing and ensures everyone gets the information needed about lessons to be learned. How do you maintain control in lessons learned sessions? |
There's No 'Root Cause' in Project Failure
Categories:
Stakeholder Management
Categories: Stakeholder Management
| "Complex problems have simple, easy to understand, wrong answers." -- H. L. Mencken When a relationship with a key stakeholder breaks down, or there is some other failure in your project, it's tempting to assume there is a 'root cause.' We think that by finding and fixing this key factor, the problem will be resolved. Many tools help find the root cause and these tools work for simple problems. However, they are dangerous to use in complex systems. The '5-Whys' approach assumes that each presenting symptom has only one sufficient cause. By asking 'why?' five times, you can drill down to the root cause. For example, say that your boss complains that her computer is not working. You see the plug is out of the wall socket. You replace the plug and solve the problem, right? Well, the answer depends on how you define the problem: Problem: Lack of power. Solution: Replace the plug. Problem: Lack of training or knowledge. Solution: Teach your boss about the plug. Problem: Poor joinery design. Solution: Put the power points on the desktop instead of on the floor. The '5-Whys' approach requires the right definition of the problem to start digging for a root cause. Even then, the approach only follows one line of thinking, which limits its ability to identify complex interactions. When considering problems in socio-technical systems, such as stakeholder relationships, the assumption that there is a single event that triggers a chain of events that lead to a problem is false. Most problems have multiple contributing causes. Each element is necessary but only when all of the elements are combined 'correctly' is there sufficient impetus to create the breakdown. When trying to understand failures in complex systems, like relationships, a different paradigm is useful. For example, let's say you used a range of motivational techniques to help your team perform that have worked well in the past. This time, however, the team disintegrated, and productivity dropped. Chances are that the problem emerged from a confluence of conditions often associated with the pursuit of success. But in this specific combination, there was "trigger failure;" each item was necessary, but on its own or in a different combination could be more beneficial. These unexpected outcomes are encountered because complex systems, like relationships in and around a project team, have emergent behaviors, not resultant ones. Complex causes require subtle management. You need to be continually prepared for nonlinear behaviors where small problems can result in large and cascading failures. Rather then resolutely applying your standard approaches, look, listen and 'tune-in' to your team. When a complex system reaches the tipping point and collapses into failure, it is too late. You need to feel the issues emerging and adapt to the changing situation. How do you detect failures in stakeholder management? Read more about stakeholder management. |
Project Management Knowledge Versus Technical Knowledge
Categories:
Leadership
Categories: Leadership
| As project managers, we have to manage various tasks in multiple lines of work. At times, we operate from our technical background and impart that knowledge and expertise more than our project management knowledge. There needs to be the distinction of when we use our "project manager hat" versus our "technical specialist hat." Many project managers work in two common extremes: process focus or technical detail focus. This is common for junior project managers and for project managers who are new to an organization. That often happens, in my opinion, because those project managers haven't developed their management style yet or haven't adjusted to the organizational culture. When the project manager thinks something is going wrong on a project, either with how someone is performing a task or the results of a deliverable, we often try to fix it. We do that with our strongest toolkit -- usually, that's our technical background. We often take over and hijack the task just to do it "our way," based on our experience. Remind yourself that as a project manager, you have a different role as a leader. You also can't be a technical skills expert for your team. Realign yourself to the deliverables. Gain a clarity of the project goal, the project management approach you are using and your role in managing the given project resources. Project managers can be quite connected and attached to the project outcome. But when you see an opportunity to improve something based on your technical expertise or what you would do differently, stay focused on your role, which is to deliver the project according to the business requirements, aligning with the business sponsor and the organization. Let your team handle their tasks according to their experience and expertise. Do you ever rely too heavily on your technical expertise? Read more from Dmitri. |