Learning to Adjust
In my last few posts I presented the Explore – Discover – Adjust model and MAQ questions for 6th Sense Analytics data analysis. Now I want to explore the most challenging aspect of the model—the Adjust phase. What makes it so challenging? Having the wisdom to determine:
A. How much change to introduce at one time?
B. For how long?
C. How to determine the effectiveness of the change?
D. Then how to guide further analysis and more adjustments…
I’ve learned the hard way that I’ve got an early adopter mentality as a leader. This drives me to try new things easily and to take a whole lot on at one time. This tendency finds its way into all aspects of my work—even when making adjustments. Given that tendency, I need to be cautious when initiating changes. Care should be taken not to take too many on at once or to assume that the organization can tolerate high levels of change all at once.
Good metrics programs need to be incremental or iterative in nature. They are part of creating a learning organization that is continuously adjusting and improving its practices. Also, as your technical, team, and project landscapes change, the same adjustments don’t always work.
Here’s an example:
- You notice that you’re team has been spending 75% of their time in coding activity for a specific project. The chart in this case is Active Time, by project / team, by activity type.
- MAQ’s in this case, point you towards analyzing:
- Is this percentage normal for this current phase of the project?
- Comparing this percentage against other activities, is the balance correct – again for this phase of the project?
- At an individual team member level, what is the variation between Min and Max?
- Is that variation of concern, more so at an overall project variance level (for risk)?
- Finally, are any adjustments in order?
- Let’s say in this particular case, the project is just beginning. Requirements are ill defined and the Business Analysts are working feverishly to write system use cases. Given that level of clarity, a 75% level of coding might be very excessive. Possible adjustments or actions to take might include:
- Investigate where the coding is occurring and ensure that requirements are reasonably clear in those areas. If not, then perhaps the construction needs to be slowed down a bit. Then, if the development team is truly “idle”, perhaps they can assist in requirement definition?
- Check if the balance of the development effort is right. If this were an Agile team, you should reasonably expect more testing time to be occurring and that 75% coding indicates a general process break.
- If you do find it to be an issue, determine what level you should be at? And also try to predict when this level might be expected? That will help you to create visible triggers for the Active Time data within the teams’ normal workflow.
In this example, the focus was on development team work balance relative to where the project is in the methodology or SDLC.
Next topic discussion:
Another example for adjusting…
Previous Post:
Taking the Time to Pause & Think
Next Post:
More Adjusting…
