Recently, my wife and I took a trip. We were at the airport. Our flight was delayed. She was sitting with her back to the window and checking the flight’s status on her iPhone. She said that we should start boarding in 5 minutes. I looked out the window and replied, “I don’t think so.” The gate was empty. There was no plane to board.
Knowledge workers are presented with an array of information, tools, and metrics. We can practically live our lives without looking up from our screens. Automation and computing capabilities have exceeded our ability to comprehend all of this data.
In this data rich environment, the value of old-fashioned, visual inspection is enhanced, and not diminished. Visual inspection gives us the opportunity to corroborate what the data is telling us. It also provides us with a tactile understanding of how our projects are progressing.
As project managers, we typically focus on the parameters of theproject box—scope, cost, schedule, and quality. We want to deliver the required scope, on-time and on-budget, with an acceptable level of quality. There are many techniques, tools, and process to help us collect and report project metrics. With these metrics and dashboards, we can be lured into only looking at the numbers, instead of the product, service, or result we are creating.
Visualizing Scope Change
In predictive (waterfall) projects, changes are generally unwelcome. Typically, scope increases without corresponding adjustments to time and cost. Change is viewed as a threat, not an opportunity.
We establish formal change control processes so that proposed changes are assessed, evaluated, and approved or denied. The requestor documents the requested change and the potential impact. The requests are then reviewed by a change control board or steering committee who only evaluate this written presentation.
Rarely, do decision makers have the ability to physically see or touch the current state of the product, let alone clearly envision the resulting impact. Subsequently, it is challenging to fully understand the requested change’s context. Providing the deciders with visual or tangible representations can be a powerful tool.
Several years ago, my wife and I remodeled a bathroom in our home. One morning, my builder called me up and said, “I am here with the plumber. I think we need to make the shower larger.” So, I went to the house and stood in the roughed in shower. My builder was right. The space was a bit cramped. So, we changed the scope and made the space larger.
Had I simply relied on blueprints and not physically inspected the space, I would have missed the opportunity to see the current state and the proposed change. I could feel the space was tight. I could also see the impact to the adjacent space of moving the wall a foot.
When developing software and applications, seeing the current process or screen and visualizing the proposed change in scope provides a huge benefit. If we can “see” or clearly imagine the change we are in a much better position to make a decision.
One of the benefits of agile project management and adaptive delivery methods is that value is delivered incrementally. The product owner, customers, and other stakeholders have the opportunity to see and review working features early and often. Throughout the development sprint, the product owner works closely with the team. They answer questions and provide real-time feedback. This interaction enables the team to quickly iterate through design-build cycles. The resultant final output is more likely meet the product owner’s expectations.
Once, I was working with a team to deliver a new project management information system. The team was demonstrating the reporting capabilities and the folder structure for organizing the information. The reports were buried 5-levels deep in a tree. After clicking through the prototype structure, I informed the team that most users would find this hierarchy difficult to navigate and suggested that they flatten it to 2-levels.
There is a story about Steve Jobs and the first iPod. The engineering team brought him the prototype. Jobs looked at the device. He played with it and declared that it was too big. The team explained that they could not make it any smaller. Jobs then dropped the device into a fish tank and air bubbles came out. He declared that because there were air bubbles, the device could be made smaller.
Seeing Quality
When building software applications, defects are a given. When Microsoft released Windows 2000, there were over 68,000 bugs—28,000 of which were expected to be “real problems.” A project goal was releasing a product with zero defects. Clearly the goal was not achieved, but Windows 2000 was an improvement over its predecessor.
A recent article from QASymphony listed 64 different software quality metrics; including:
- 12 fundamental metrics
- 11 defect distribution charts
- 8 test tracking and efficiency metrics
- 5 test effort metrics
- 5 test economics metrics
- 4 test coverage metrics
- 4 test team metrics
- 4 test effectiveness metrics
- 2 test execution and status metrics
The ability to analyze, comprehend, and contextualize all these metrics is beyond human capacity. When you overlay the number of test cases, defects, etc. with the metrics the data becomes staggering. Visually inspecting the product by using it and seeing the impact of the defects is a critical component of the testing lifecycle.
When it comes to building physical products, visual inspection is easy. We can see the contrast between expectations and outcomes. It creates the opportunity to view options and outcomes in a different light. Or, we may find that our requirements or specifications were not good or did not convey enough information.
As the builders in our house were putting down the new bathroom tile, my wife and I noticed that the natural striations in the granite were creating an odd visual affect. We had not considered this potential outcome. Had we not been walking through the job site, we would hot have seen the pattern. Nor, would we have identified the easy solution of changing the order of the tiles.
Microsoft is known for using the “good enough to ship” standard for its software which means that it has known defects, but it ships with the right bugs. To determine which defects are acceptable, developers, testers, project managers, and sponsors must understand the implication of the bugs. With Windows NT, Microsoft established the practice of dogfoodingwhere the team used the previous day’s software build for that day’s work. You can imagine how quickly they understood the criticality and importance of each defect.
Understanding Schedule Variances
Project schedule and cost data is relatively straightforward. We create our timelines and due dates. It is easy to compute schedule and cost variances. We have a numerical amount that was planned along with a similarly measured actual.
Understanding these variances is often nuanced and more complicated. Many times, I have been told that a work item is 80% complete. Long ago, I learned the last 20% can take more time and effort than initial 80%. Incorporating visual inspection into the variance analysis provides a deeper understanding of progress.
On projects where we are creating a physical product, visual inspection is easier. We can count the number of widgets produced and compare that to the plan. When it comes to projects where we are creating a service or result, physical inspection and measurement becomes harder.
For projects where it’s difficult to physically inspect and measure progress, it is often a good idea to measure accomplishments in small increments. In other words, create a schedule that allow you to tangibly measure progress every couple of days, rather than waiting a week or longer. For example:
- If you are managing the creation of a report or document, set milestones for the drafting and review of each chapter; rather than the delivery of the final report; or
- If you are developing application software, set milestones for the development of discrete features; rather than the completion of the entire module.
By establishing short-term deliverables, where we can visually inspect and calibrate progress, we can reduce the likelihood that our project data leads us astray. We can more closely correlate physical completion with the information we receive.
Visual inspection takes the project manager out of the office and puts them with the team. It provides the project manager with valuable information. It also creates transparency and the opportunity to collaborate more openly. Give it a try.
© 2018, Alan Zucker; Project Management Essentials, LLC
To learn more about our training and consulting services, or to subscribe to our Newsletter, visit our website: www.pmessentials.us.
Sources:
Bach, J. (1997). Good Enough Quality: Beyond the Buzzword. [online] Satisfice.com. Available at: http://www.satisfice.com/articles/good_enough_quality.pdf [Accessed 10 Jul. 2018].
Chaudhary, A. (2011). What are some great stories about Steve Jobs?. [online] Quora. Available at: https://www.quora.com/What-are-some-great-stories-about-Steve-Jobs/answer/Amit-Chaudhary [Accessed 10 Jul. 2018].
En.wikipedia.org. (2018). Eating your own dog food. [online] Available at: https://en.wikipedia.org/wiki/Eating_your_own_dog_food#Origin_of_the_term[Accessed 10 Jul. 2018].
Foley, M. (2000). Bugfest! Win2000 has 63,000 ‘defects’ | ZDNet. [online] ZDNet. Available at: https://www.zdnet.com/article/bugfest-win2000-has-63000-defects/ [Accessed 10 Jul. 2018].
QASymphony. (n.d.). 64 Essential Test Metrics For Measuring Software Quality, Testing & More!. [online] Available at: https://www.qasymphony.com/blog/64-test-metrics [Accessed 10 Jul. 2018].
Zucker, A. (2015). The Project Box—Evolving Beyond the Triple Constraint – Project Management Essentials. [online] Project Management Essentials. Available at: https://pmessentials.us/the-project-box-evolving-beyond-the-triple-constraint [Accessed 10 Jul. 2018].
Image Courtesy of: https://mobilerving.com/blog/avoiding-food-poisoning-on-the-road-the-visual-inspection