Management by Bleep

There are some ways of managing projects. A way of classifying them is:

• Management by Objectives: employers get there goals to reach and the manager has a facilitating role;


• Management by Directive: manager tells the employer what to do;


• Management by Walking around: manager checks on the floor on frequently basis if every thing is done the right way;


• Management by Exception: only when things are getting out side the defined borders management gets involved

I will not say one approach is good or one is bad. I think it depends on the situation. In testing it can be the same and during the project situations can change.

Sometimes when a project starts you develop a master test plan and detailed test plans. In these test plans you also mention what the entry criteria how the communication will be with other members of the teams like developers and more. You start with a bright vision and a clear view.

During the project some decisions are made. Those decisions have impact on your test process and the style of management. What will you do when:

• Requirements and functional design are frozen while they are not SMART yet;
• The test environment is no longer of your control, development can deploy when ever they want;
• The system is not stable, as older issues are returning again;
• The test scenarios and test cases are only focusing on code which would be probably delivered the next time and not covering all functionality;
• Due to unclear FO's newer requirements are showing up, issues are rejected as it was not specified;
• And a few more

A possible strategy would identify the risks and tells it to project management. Seems that the management style turned into Management by Exception. Only what management style is involved when all risks are accepted? To me it seems you are no longer in control of the test process as you intended in your test plan/strategy.

What I see and hear in some projects is that the manager goes with the flow and acts on bleeps. If the system makes a bleep or a tester bleeps out loud then the manager interferes. The manager keeps managing what is still manageable for him and if one of the mentioned risks becomes real he acts. This action is triggered by the bleep. A kind of Management on Bleep.

Now I'm wondering if it can be done using multiple management styles by one person. Or is this still Management By Exception?