Mind Mapping: Digital Transformation of Projects & Design Process

Using Operational Data

The Challenge:

I am a Project Manager in a Consultancy firm, challenged with managing the implementation of and  coordination of many digital transformation projects that have been highlighted as being of strategic  importance to the client. The project in question is geared towards using operational data from their  portfolio of buildings for the purpose of the asset management team being able to more effectively  manage the property in terms of reliability and maintenance, as well as providing data driven  insights to ensure that the provisions specified more closely meet the needs of the tenants, by  generating best practices and guidelines.

The issues that I was facing is that there was a wealth of possibilities with none of them being  documented, and that there was a risk of important possibilities being missed if they were not  drawn out of the correct stakeholders. This problem was compounded by the fact that the relevant  team members were dispersed across South East Asia, and the inability to travel due to Covid  restrictions meant that I had to get creative with my approach!

The Approach: Tools & Application:

Having met most of the team members on various video calls, I knew that they were highly  frustrated with the cyclical, manual aspect of their work, with the same insights having to be created  over and over; I knew that I had to capitalize on their frustration. I had also deduced through some  internal approach meetings that there is a culture of debunking ideas due to an inherent lack of  evidence that the idea is a good idea, meaning ideas rarely get off the ground; a factor I had to work  around with my approach.

When reading my notes for this course, I was compelled by the statement “If anything was possible,  what criteria would our design meet?”, so much so that I felt the need to write the direct quote and  highlight it!

To leverage the group’s frustration, I decided on a mind mapping approach of identifying “pain  points”; as the group was dispersed, they were briefed as a group, then instructed to provide the  pain points to someone assigned to aggregate. I was fully aware of the risk of this method, as it risks  a lack of participation, but given the constraints it was necessary; but due to the level of frustration,  pain point submission was very high.

Once aggregated, the group came together to look for themes and pattens in the pain points,  creating 13 categories hat would form the project work streams going forward. The statement of “If  anything was possible, what criteria would our design meet?” was integrated by holding use case  generation workshops, where the group defined (for each pain point/ group of similar pain points)  how we could use data to alleviate the pain point defining data Use Cases, heeding the advice of  Marin Moore in the Mind Mapping video to ask “so what?” until what is truly valuable to the  stakeholders is clearly stated. , The team then agreed on hypotheses that must be true in order for  the use cases to be worthwhile implementing. Once this was bottomed out, the perceived value-add  (to the client, to their tenants, and to their end customers) was defined.

Only once this five-step process was complete:

Pain point → Use Case → Hypotheses → prove Hypotheses → Define Value Add

Could we progress to prioritization of the defined workstreams.

Insights:

It was clear to me that the Idea Generation methodology above has a major flaw, as do all lean idea  generation methodologies geared towards ideation via creativity; the less flashy ideas get forgotten  due to the draw of the more interesting ideas. To counter this, I thread a different project’s output  into this project as an input; that project having their primary focus to be defining the data  requirements needed to create a machine learning system that provides design specifications. The  less attention-grabbing specifications (such as toilet gender ratio data per client type), was identified  and plugged the “boring topic” gaps.

A key take-away from this process was that at the beginning of the process, each department felt  that their pain points were the most significant as it was based on pain they had personally felt;  however after going through the stated process, there was little to no dispute regarding the  prioritization of each work area. Even more amazingly, the outcome was that the top priority  workstream was only brought up by a small number of people as a pain point (real-time indoor air  quality measurement) as this is seen to be an issue that will grow going forwards, as wellness  become more of a focus in work spaces.

Due to the forward looking nature of the top priority workstream, this project is now being reshaped  into the base of a continuous improvement engine, where the five-step process outlined above is  carried out quarterly, with a focus on what operational data must be leveraged, and how, to be at  the cutting edge of our industry.

This experience (as well as knowledge sharing with others doing similar things) that the speed of  sprint methodology is proportional to the accessibility and veracity of the required data, and when  doing this again, I will factor this into the sprint timings.


Mind Mapping : Digital Transformation of Projects & Design Process Using Operational Data The Challenge : I am a Project Manager in a Consultancy firm , challenged with managing the implementation of and coordination of many digital transformation projects that have been highlighted as being of strategic importance to the client . The project in question is geared towards using operational data from their portfolio of buildings for the purpose of the asset management team being able to more effectively manage the property in terms of reliability and maintenance , as well as providing data driven insights to ensure that the provisions specified more closely meet the needs of the tenants , by generating best practices and guidelines . The issues that I was facing is that there was a wealth of possibilities with none of them being documented , and that there was a risk of important possibilities being missed if they were not drawn out of the correct stakeholders . This problem was compounded by the fact that the relevant team members were dispersed across South East Asia , and the inability to travel due to Covid restrictions meant that I had to get creative with my approach ! The Approach : Tools & Application : Having met most of the team members on various video calls , I knew that they were highly frustrated with the cyclical , manual aspect of their work , with the same insights having to be created over and over ; I knew that I had to capitalize on their frustration . I had also deduced through some internal approach meetings that there is a culture of debunking ideas due to an inherent lack of evidence that the idea is a good idea , meaning ideas rarely get off the ground ; a factor I had to work around with my approach . When reading my notes for this course , I was compelled by the statement “ If anything was possible , what criteria would our design meet ? ” , so much so that I felt the need to write the direct quote and highlight it ! To leverage the group ’s frustration , I decided on a mind mapping approach of identifying “ pain points ” ; as the group was dispersed , they were briefed as a group , then instructed to provide the pain points to someone assigned to aggregate . I was fully aware of the risk of this method , as it risks a lack of participation , but given the constraints it was necessary ; but due to the level of frustration , pain point submission was very high . Once aggregated , the group came together to look for themes and pattens in the pain points , creating 13 categories hat would form the project work streams going forward . The statement of “ If anything was possible , what criteria would our design meet ? ” was integrated by holding use case generation workshops , where the group defined ( for each pain point/ group of similar pain points ) how we could use data to alleviate the pain point defining data Use Cases , heeding the advice of Marin Moore in the Mind Mapping video to ask “ so what ? ” until what is truly valuable to the stakeholders is clearly stated . , The team then agreed on hypotheses that must be true in order for the use cases to be worthwhile implementing . Once this was bottomed out , the perceived value - add ( to the client , to their tenants , and to their end customers ) was defined . Only once this five - step process was complete : Pain point → Use Case → Hypotheses → prove Hypotheses → Define Value Add Could we progress to prioritization of the defined workstreams . Insights : It was clear to me that the Idea Generation methodology above has a major flaw , as do all lean idea generation methodologies geared towards ideation via creativity ; the less flashy ideas get forgotten due to the draw of the more interesting ideas . To counter this , I thread a different project ’s output into this project as an input ; that project having their primary focus to be defining the data requirements needed to create a machine learning system that provides design specifications . The less attention - grabbing specifications ( such as toilet gender ratio data per client type ) , was identified and plugged the “ boring topic ” gaps . A key take - away from this process was that at the beginning of the process , each department felt that their pain points were the most significant as it was based on pain they had personally felt ; however after going through the stated process , there was little to no dispute regarding the prioritization of each work area . Even more amazingly , the outcome was that the top priority workstream was only brought up by a small number of people as a pain point ( real - time indoor air quality measurement ) as this is seen to be an issue that will grow going forwards , as wellness become more of a focus in work spaces . Due to the forward looking nature of the top priority workstream , this project is now being reshaped into the base of a continuous improvement engine , where the five - step process outlined above is carried out quarterly , with a focus on what operational data must be leveraged , and how , to be at the cutting edge of our industry . This experience ( as well as knowledge sharing with others doing similar things ) that the speed of sprint methodology is proportional to the accessibility and veracity of the required data , and when doing this again , I will factor this into the sprint timings .