From your project’s blind spot and hidden area to known area using the Johari Window Model.
Your team has again implemented a sub feature that needs to be removed? You have noticed that the reason for removing this feature was already known by some. Newly implemented interfaces have to be adapted based on problems that were created a long time ago, and you wonder how often such situations will occur before the release? Looking at it from a different perspective, with the Johari Window Model focused on the project, might help you find a solution.
What is the Johari Window Model?
In short, the Johari Window Model reveals what others know and don’t know about me, and what I know and don’t know, by representing the subject in a 2x2 matrix. It is a model designed to support your growth in self-awareness and relationship with others. If you would like to learn more about the model, I recommend this website.
In general: The goal is to have a large open area and reduce the other three areas (blind spot, facade & unknown area) which supports communication and collaboration. Tasks and ideas on how to increase the open area are also mentioned on the above page.
I would like to use this model as a mixture of mindset and tool for your daily work and frequent checks. It will support the team and stakeholders to have a common, high quality view of the status and content of a project instead of the original use for relationships with yourself.
The importance of a common view is well known. There are already tools from project management and agile frameworks, that are support this, some are:
- Project Profile, Project Plan, Schedule, Work Breakdown Structure, Project Objective, Specification, Ticket System, Quality Gate
- Backlog, User Story, Sprint Review, Burn-Down-Chart, Objective
Why should I add anything additional?
The common tools within a project are well known. There are also many inputs which, due to the complexity of the project, lead to a huge blind spot and hidden area:
- The size of the project, like a car with several sub projects
- Number of locations
- Number of companies involved
- Process optimizations during the project
- New technology development without proof of concept
What kinds of situations might be based on such an environment?
- Sub-projects mean sub-scope. Without a perfect traceability and communication between different project levels, it often happens, that a new or obsolete feature is introduced at one level without communication to all relevant stakeholders.
- Issues during development (or from the last release) are not created in the expected way (human error or being not aware of new process), with the expected tool (cause of no access) or with old parameters (process has changed but not changed for all tickets).
- There are common views and filters, but people often like their own. Some show a different scope from the beginning without notice, some later, when process improvements are in place, but people missed to update their views and filters.
Why don’t they use the common ones?
- Some prefer their own visualization of the same content.
- Other have to work on other projects in parallel and need combined views.
- They have used the right ones, saved the bookmarks, but failed to update them when the project changed and are still using the original ones. - Misinterpretation of content, e.g. after adjusting the project scope and main communication via presentations leading to the use of reduced information. Features have been reduced, but there is no common view of the reduced new definition.
How do you handle such situations?
The focus is not on increasing quality mechanisms so that such errors can’t happen. It is about adding some lightweight actions and a general mindset to move the blind spot of a project plan and hidden area for stakeholders, based on already existing knowledge, to the open area to detect miscommunication and errors earlier.
Using “project plan” and “stakeholders” is just one possible view, e.g. project plan can be replaced by backlog or something else, depending on the situation.
Very important: Moving issues to the open area does not directly improve the project situation. But it does give the stakeholders a chance to react to unexpected feature requests, opinions, and other misunderstandings. They can then adjust the scope, priorities, schedule, or other actions as needed, and work more efficiently on the most important features.
What additional techniques can increase the open area?
General: Anything that supports multiple seeing the same data will support this. Very important. It is not about mistrust! Rather, it is about recognizing that we are humans and that miscommunication and failure will happen. Especially in a VUCA environment with time-critical situations, high complexity, frequent impactful changes, the rate of errors will increase.
Check:
- Pair programming light. Go to your stakeholders and ask how they see the project: Look at the tickets or the backlog. The stakeholders should show you how they are structured, and then switch roles. The “light” is added by me to highlight the difference of just checking frequently instead of creating all views together all the time (which could be an idea for the start of the project or big process changes).
- For me, this is also an underrated technique for other areas like requirements writing, test case specification, etc. Because it helps most of the time to start directly with high quality results. - Create checks for your tool:
- Create a visualization that shows the distribution for all tickets between the last update and now.
- Check your parameters for unexpected values, e.g. obsolete values from the previous process.
- Most modern issue tools provide such checks for free, be curious to use them. - Run a quick check of all your input files and tools as soon as you receive them and run plausibility checks on your own delivery of such files.
- Files: Compare the new version with the old one (e.g. SVN compare). Better, import or use the files directly.
- Tools: Rebuild and/or retest your software etc. with the last working setup or a golden sample.
Share:
- Use your visualizations, numbers, etc. most of the time during discussions and meetings. Give everyone a chance to see that their own view/expectation might be different.
- Share sprint, intermediate plans and results with a few more stakeholders. For example, if you are implementing the server module, share it with at least one client module.
Explore:
- Note: This part is additional to “Share” and “Check” because it focuses on the unknown issues instead of the known but mis-communicated ones. It completes the idea of using the whole Johari Window Model for projects.
- Perform proofs of concept, align on spikes, and share ideas and results; someone else may have additional information to accelerate proofs of concept.
Anything that supports multiple eyes seeing the same data will support such situations — what other ideas do you have? Please comment!
How efficient are these additional tasks and checks?
There are no own measured numbers about additional effort or time and budget savings. I refer to the publication “Integrating Software Assurance into the Software Development Life Cycle (SDLC)”.
They have measured their relative cost of fixing defects (see figure) over the phases of the SLDC, showing the exponential increase in the cost of fixing defects. By moving issues into the known area defects can be caught earlier, which means a huge reduction in cost and time instead of finding them later.
For me all actions are light weighted and if you find a bug, you would spend at least the same time in a later phase just for the retrospective part to check why the bug happened. So if you find a bug during such an action, your project will save the total cost of finding the bug later. In a project with fewer surprises, you have to calculate the cost savings with the cost of the actions, and the result could be negative. Together with some real-world situations mentioned at the end of this article, you should be able to evaluate whether such an effort could support your project or not.
Think about your own project. How much work would you do if part of a feature was implemented and tested even though some stakeholders knew it had to be cancelled because current sensors can’t support the feature? Or an interface needs to be redesigned because of overlooked security or customer issues, feedback that was handled in a different system or with different parameters? Compared to this, the additional actions will save a lot of time (delay) and money.
Why is it also a mindset issue?
It is about the important awareness that there will always be miscommunication and gaps, even if the project plan and scope were aligned at the beginning. And it is about changing the way we work to include more sharing and checking as standard in many situations, not just at the basic quality gates or milestones.
What’s the takeaway?
In the case of a project with a lot of change and miscommunication, still trust your people and include some of the above checks and information sharing for important issues and you will move them to known area to save time, effort and cost.
Who writes?
My name is Jürgen Geißler, I have 16 years of experience in system and software development in the automotive and medical device industries and I am working for Luxoft as a project manager and in similar roles. My passion is to create an open environment that allows continuous development of employees and the way they work together, and where results are aligned with added value for the customer. Most of the time I am in a role to get internal or customer projects back on track or off the ground.
Appendix: What are some real-world scenarios?
- The sensor team agreed with systems engineering to cancel a feature because the sensor could not support it and no other solutions were known. At the same time, the product owner would coordinate with the GUI team on the content for the canceled feature. This happened frequently and caused a lot of unnecessary work. As a result, the GUI team always shared the next sprint with more stakeholders to give them a chance to react directly.
- Issues raised during user acceptance testing between the product owner and users were not seen as issues by other stakeholders because the product owner did not have access to the tool that handled issues. Instead, they created issues in a different project tool for user stories using a different issue type. This was discovered when the product owner shared an issue about user acceptance testing and a parallel review of the open issue list. While doing this, other important issues were found, and the only possible action was to delay the release date, user acceptance tests, etc.
- Suppliers have only received a subset of issues, because many issues are in another subset. Project management has only checked the number of supplier issues, without knowing the total or pending issues. This was discovered during the 1-on-1, when the project manager was talking about the number of tickets from each supplier, and in parallel knew that the number of open tickets was twice as high as mentioned. Resolving such a number of open tickets was not part of the suppliers’ latest plans, and the only possible action was to postpone the release date, user acceptance tests, etc.
- The scope needs to be reduced to meet the release date. The Service GUI feature should be retained in this release. The service under this term means the GUI with all previously aligned parameters such as sensor service values, etc. All other stakeholders understood a GUI with a minimal subset to support only software updates from the service. This miscommunication was caught during the software release quality gate. There was no additional change, but trust was lost.