Management Bits and Tips

Metaphorical mapping from False Positive Dump pattern brings us to False Project Failure pattern that usually happens when assessing the current project status leads to overestimating its potential failure and stakeholders think that actual failure has already happened. Let me bring an example from my own software engineering experience. One of software developers was assigned a project to develop a wizard-like installation system tightly integrated with voice recognition. Due to some reasons I don’t want to discuss here the system wasn’t developed and we faced demonstration of it in front of VP on the next day when we learnt about the nonexistence of even the prototype version. However that was only potential failure not turned to actual because we managed to create a working prototype overnight by typing screen dialogs in MS Word, print screening them to bitmap files, drawing Next and Prev buttons in MS Paint and crafting a small GUI program that sequentially displayed these pictures based on whether mouse clicks were in the region of painted buttons. The prototype was working like the clock and VP was so impressed that he didn’t even have questions to ask. The project was abandoned in another 6 months but this is another story and a different pattern. 

- Dmitry Vostokov @ ManagementBits.com -

I’ve created a page that lists existing and future patterns:

http://www.managementbits.com/project-failure-analysis-patterns/

- Dmitry Vostokov @ ManagementBits.com -

What is an equivalent to computer memory in organizations and teams? It is the collection of various artifacts including project documentation, source code, financial documents, etc. What is a computer memory corruption? It is a deviation from expected memory contents that may or may not lead to a crash or a hang but the chances of that are increasing over time. Metaphorically we can consider deviations from requirements or expected documentation content to be some sort of a corruption that might slowly lead to a project failure over time. Surely “project memory” or “organization memory” is dynamic or heap-like in nature as documents are added to a pile or removed from it. Therefore we have just established the mapping between Dynamic Memory Corruption pattern from crash dump analysis domain to Project Artifact Corruption pattern. 

- Dmitry Vostokov @ ManagementBits.com -

Recall from my motivation for this pattern series the analogy between the following entities:

• Computer Application/Process - Team

• Thread of activity - Team member

• Operating system - Company organization and management

• Computer system - Company organization and management plus teams

• User process dump - Team state snapshot

• Kernel memory dump  - Organization state snapshot

• Complete memory dump - Organization state plus teams internal state snapshot

• Exception - Fault, mistake

• Crash or hang - Failure

The first pattern is called Multiple Faults and it is a direct mapping from application crash analysis Multiple Exceptions pattern. The running instance of a computer application (process) can experience multiple exceptions from different execution threads before it hangs or crashes. The latter causes the process to disappear from external observers watching Task Manager. The same can be true for any functional team. Multiple faults from different team members can happen and if a team fails we shouldn’t attribute the overall failure to just one member’s fault that is on a surface but look for other possible mistakes too. 

- Dmitry Vostokov @ ManagementBits.com -

There is something similar, at least metaphorically, between computer system crashes and hangs and software project failures. Software projects deliver software that crashes and these software failures via negative feedback loop either slow projects down or simply lead to their abandonment. The structure of a software development team resembles that of a running application (called a process) with team members acting in parallel (threads) and the structure of operating system with multiple running processes competing for resources resembles a software company struggling to stay alive. When projects fail there is something left as artifacts available for study and the same is true for crashed processes or operating systems leaving crash memory dumps behind for postmortem analysis.  

In some future posts I’m going to map Crash Dump Analysis patterns to Project Failure Analysis patterns and see what comes out of this attempt.

- Dmitry Vostokov @ ManagementBits.com -