Delivery Documentaries are a behind the scenes look at how our Enterprise Architects (EAs) in the field perform Value Realization activities for customers. The documentaries are raw and real, and the purpose is to share what actually happens on the ground. They are always a learning opportunity, and we hope that over time we can help bridge the state of the art with the state of the practice, and continue to move the ball forward.

What happens when a business that is struggling with a problematic project brings in a Microsoft Architect to help create a recovery plan? Let’s see…

Executive Summary

This is a Delivery Documentary of an engagement led by the Microsoft Enterprise Strategy Program (ESP), which provides services to help customers realize the most value from their technology investments. In this engagement, the Enterprise Architect led a team in diagnosing issues with a problematic project and recommending a recovery plan.

How It Started

This project involved assessing and correcting the course of an existing project: developing a customer relationship management (CRM) system using agile methodology. As the deliverable for this engagement, the sponsors requested a new roadmap for the project that accounted for the current organizational goals.

Initial Research and First Meeting

I reviewed the available information on the project to date, including the engagement proposal, the existing project roadmap, and the previous status presentations and other presentations about the engagement’s history and issues.

We held the first meeting with the executive stakeholders to define the engagement and set expectations. To address problems arising from a lack of communication during the initial project, we recommended that we create a governance board to receive weekly status reports on the engagement. The stakeholders agreed, and the board consisted of the following members:

Internal product manager for the original project
Executive stakeholders from each business division
Other business stakeholders (directors, CIO, user representatives)
Managing architect for the account (from Microsoft)
Delivery practice manager (from Microsoft)
Executive stakeholders (from Microsoft)

I explained that we would gather data about the project by holding workshops with the employees that would be using the CRM system at the agency headquarters and in each of the affected divisions. I asked the business stakeholders to recommend participants for the workshops, including representatives of the IT group that would be supporting and managing the system. To ensure that everybody involved had the same understanding of the workshops, I requested that all participants attend a single kickoff meeting.

Assembling a Team

I gathered the resources I would need from both Microsoft and the business. We brought in a Microsoft CRM expert to act as a SME with regard to the project itself. The company provided a resource to help schedule meetings and workshops, and a SME who was familiar with both the business and the technology of the organization.

The team would provide insights into daily operations, as well as the applications and infrastructure that employees used. In addition, the team also reviewed the models of business and technology processes, and provided feedback.

Gathering Data

We conducted workshops separately for the headquarters of the organization, and for each division that the CRM system affected.

At the workshops, we collected information from employees, including:

What were their goals and business motivations?
What problems or barriers prevented them from reaching their goals?
What current or planned features or initiatives were useful in reaching their goals, and which were not? What new features or initiatives would be useful?

We asked participants to assign ranks and weights to these goals. We could then prioritize the problems and features based on the goals they impacted.

Analyzing Data and Developing Recommendations

We analyzed the data for each business division, as well as across all divisions. The rank and weight assignments provided raw data for statistical analysis. We used methods such as standard deviation to refine cases where participants in a single group provided ranges of rankings instead of consistent rankings. We also examined dependencies, patterns, agreements, and disagreements both within and across divisions.

The various divisions did have some common goals and initiatives, but they also had markedly different priorities. For example, some employees saw no value in the CRM system because the features that had been implemented so far were not useful to them.

Some groups had conflicting priorities: For example, in one division, employees who answered phone requests from customers were rewarded for keeping the calls as brief as possible; as a result, they collected minimal information from the customers, and often neglected to collect and record the information needed by other divisions.

Other factors in the analysis included, for example, observations that communication issues between the divisions were a recurring problem, and the processes that the CRM system was supposed to support were not well documented. We also noted mistakes that had been made over the course of the project.

We identified themes that would impact the final roadmap. Updating the roadmap itself was primarily the work of the CRM SME. In addition to the roadmap itself, we prepared general recommendations for improving the structure and governance of the project, and for improving the relationships between the parties involved.

As part of these recommendations, we emphasized that the business continue using the governance board that was established for this project, and expand the board to include both field representatives and representatives of stakeholders higher in the organization.

Final Delivery and Outcome

The stakeholders accepted the updated roadmap and recommendations that we presented, and agreed to resume the project with our help.

Key Actions and Lessons Learned

The following actions on our part were key to forming a great relationship with the business and becoming trusted advisors to the stakeholders:

We used a sound approach for collecting and analyzing information, based on our previous experiences.
We provided weekly status updates, preventing surprises.
We used an inclusive approach. Our workshops included field employees and the IT people who supported them. In fact, workshop participation helped open lines of communication between the field and IT.
We collected data from the personnel at the organization headquarters and the field personnel separately, in order to encourage frank discussion.
We collected data as impartially as possible, recording all comments and feedback for future reference without filtering it.
We scheduled a single meeting with all of the participants for major presentations, important in light of the internal communication issues we had observed.

In general, this engagement demonstrated that:

Regular evaluation and course correction are crucial for large projects, especially agile development projects.
Users object when encountering too much change too quickly, especially if they cannot perceive a significant benefit from or justification for the change. An attempt to change processes must begin with a thorough understanding of the users and the current process.
The sequence and combination of feature releases must be planned carefully so that each release provides value to users.