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…
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.
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.
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:
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.
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.
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:
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.
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.
The stakeholders accepted the updated roadmap and recommendations that we presented, and agreed to resume the project with our help.
The following actions on our part were key to forming a great relationship with the business and becoming trusted advisors to the stakeholders:
In general, this engagement demonstrated that: