By Alan Zucker
August 2, 2023
Software projects have two measures of success. First, building and implementing working software. Second, having people use and adopt it. Project managers tend to focus their attention on delivering the application. But the project’s real success rests on user adoption.
Once, I led a large project. The application was delivered on time, on-budget, and with the documented scope. But it was not embraced and was abandoned shortly after implementation. The development team was devastated. From their perspective, the project was a success. From a business perspective, it was an abysmal failure.
This experience is not unique. In my consulting practice, I see development teams struggling with their users. It is hard to get their time and attention. To document requirements you should provide feedback on demonstrations, create and execute meaningful tests, and finally, accept and use the software.
Why do “good” projects fail? A primary reason is poor stakeholder engagement. Engaged executives and users, and clear requirements are leading predictors of project success.
Organizational change management (OCM) is the domain intended to support the adoption of new ways of working. However, history demonstrates that change is hard. Successful efforts require patience and a long-term executive commitment.
Few organizations invest in the change management capabilities required to support new technologies and business processes. The responsibility often falls to project managers. However, they generally lack the capacity and skills to support both efforts effectively. Also, their engagement is limited and often ends shortly after the software is deployed.
So, what can project managers do to improve adoption?
Assume Failure and Plan for Success
Both project and organizational change management efforts have dismal records, with roughly only one-third being successful. We should be realistic and expect that our projects will face many challenges.
So, we should assume failure and proactively plan for success. Common risks include:
- Lack of stakeholders and executive engagement. This is an early warning indicator that the project will be challenged.
- Poor alignment with project objectives and expectations. Misalignment can occur within the leadership team, and between leaders and their staff.
- External events will impact the project’s execution, including leadership and key-resource changes, market competition, and other operational changes.
Things will not go according to plan. There will be changes to the scope, priorities, schedule, or cost.
To be prepared for these challenges, actively manage the project risks. Document new risks when they are identified. Develop mitigation strategies. Regularly survey the environment. Document and interrogate all assumptions. Do not be surprised.
Once, I led a major program that the chief financial officer and chief risk officer enthusiastically supported. A few months before implementation, both left the company. Organizational buy-in did not exist, and support for the project evaporated.
Build Left-to-Right
Incremental and iterative delivery is a core agile practice. Incremental means the project is delivered in small phases. Iteration means the solution evolves and is improved based on feedback. We should plan our development to build small, usable components that allow users to regularly review, validate, and provide feedback on the emerging application.
Demonstrating the end-to-end business process should drive planning. Develop and test the system in small components from left-to-right, creating a logical flow of work. The objective is to demonstrate recognizable components in a workable progression. This allows users to validate the work progressively.
Create a map outlining the business process flow. Then begin describing the high-level requirements. Categorize the requirements as primary and secondary. Primary requirements are the bare minimum needed to demonstrate a process or sub-process; for example, extracting and loading data without applying any validation or transformation rules. Once the walking-skeleton is built, it incrementally expands its functionality.
Demonstrate Early and Often
Traditional project management practices rely on an engineering model. Develop detailed specifications upfront and then build to those specs. The model is imperfect for construction and fares worse for software.
Using working software to measure progress is an Agile principle. Rather than relying on voluminous written documentation to describe the application, lightweight tools such as wireframes, mock-ups, and other low-fidelity prototypes are used to understand user needs.
Prototyping avoids the “I’ll know it when I see it” trap. Users can see how things will work rather than envisioning how the written documentation will be implemented. It also reduces the significant effort required to create and maintain requirements and design documentation.
I was the project manager for a mission-critical application. We developed the application based on successively more detailed screen mock-ups. The prototyping tool allowed us to capture the data needs and process flow quickly. Since users played an active role in developing the application and validating the functionality, adoption was fast and easy.
Shift Left
DevOps introduced the concept of “shifting left” and promotes moving quality practices earlier in the development lifecycle. We can apply this practice to engage stakeholders early and regularly throughout the development process.
Practices that shift engagement and quality left include:
- Involve users when developing the delivery roadmap. This will allow you to demonstrate and potentially implement small pieces of functionality sooner
- Have users document clear acceptance criteria along with the requirements. This will provide compelling and more thoughtful elicitation of what is needed
- Actively engaging users during the design phase to provide feedback on the screen design, process flow, and business rules
- Hold regular demonstrations of working software components to users to collect feedback
Create Flow
Lean practices focus on the flow of work. We create flow by visualizing the process, working in small batches, minimizing work-in-progress, and honoring constraints.
Kanban is an effective tool for managing flow. Business teams should use Kanban boards to track the progress of their project efforts and contributions, such as creating requirements, providing feedback, testing, and approving delivered components.
Recognizing and resolving issues early avoids bottlenecks and quality problems later in the process. Business users rarely have the bandwidth to support the project and their operational responsibilities. Development proceeds with incomplete requirements, and there is a pile-up before acceptance testing. Recognize and address these constraints rather than ignoring them.
Energize the Champions
Champions play a critical role in helping the rest of the organization adopt the new application. In every organization, there are leaders, watchers, and resisters. Leaders embrace change. Watchers take a “wait and see” approach and are heavily influenced by early indicators of success or failure.
Identify leaders early in the project. Look for those who are enthusiastic and influential. Engage them in the design and development process. Actively solicit their input and feedback. Create a sense of ownership to build their support. Have them validate the application’s functionality. Install them as subject matter experts and (potentially) as trainers. Leverage their enthusiasm to motivate the rest of the organization. Create an environment where there is no option but to succeed.
About the Author
Alan Zucker has over 25 years of experience leading projects and project management organizations in Fortune 100 companies. In 2016, Alan founded Project Management Essentials to share his passion for and experience in project management, leadership, and Agile.
Alan is a frequent keynote speaker and thought leader. He authors monthly articles, is regularly quoted in the industry press, and is a podcast guest. He is an adjunct faculty member at George Mason University and the University of Georgia; and is a senior instructor with several national, professional development organizations.
Alan has a master’s degree in economics from the University of Maryland and a master’s and a certificate in IT Project Management from the George Washington University. He is a Project Management Professional (PMP) and Certified Agile Professional (PMI-ACP) through the Project Management Institute. He also holds multiple Agile certifications from Disciplined Agile, Scrum Alliance, and Scaled Agile.
Visit Alan’s social media links to learn more.
Website: https://pmessentials.us
LinkedIn: https://www.linkedin.com/in/alanizucker/
Twitter: Alan @pmessentials_us
Browse IIL’s Project Management Courses here!
Registration for IPM Day 2023 is open! Check it out here.
Disclaimer: The ideas, views, and opinions expressed in this article are those of the author and do not necessarily reflect the views of International Institute for Learning or any entities they represent.
