Project Success: Implementation AND Adoption

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 struggle with their users. It is hard to get their time and attention. To document requirements. 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 [1]. 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 [2].

Few organizations invest in the change management capabilities required to support new technologies and business processes. The responsibility often falls to the project manager. 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 [3] and organizational change management [4] 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 stakeholder and executive engagement. This is an early warning indicator that the project will be challenged.
Poor alignment on 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, incrementally expand the functionality.

Demonstrate Early and Often

Traditional project management practices rely on an engineering model. Develop detailed specifications up-front 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 processing 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 allowing them to demonstrate and potentially implement small pieces of functionality sooner;
Have users document clear acceptance criteria along with the requirements—compelling a 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; and
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. The leaders embrace the change. The 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. Hve 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.

See related articles:

To learn more about our training and consulting services or subscribe to our newsletter, visit our website: http://www.pmessentials.us/ [8].

Image courtesy of: TexSix.com