In the past I have written about meetings, where Information is being brought into the session, on which basis Decisions are being taken, and Actions agreed. Everything that happens professionally in that meeting can be categorized as such.

The same basis is also reflected in organizations: a Project Manager is responsible for the process, so to ensure that transparency is created, information about the status of the project is shared. On that basis, the Review Committee can make decisions, which Project Team resources need to do.

Levels of abstraction

Similar to the structure of information in meetings, if in an organizational project administrative tasks like process descriptions  need to be written, a process manager usually will write the process description, the process owner would have to approve it. For IT applications exactly the same applies, just the roles are named slightly differently: Application Owner and Application Manager.

To keep a clear distinction about what the tasks are of each individual parties it might make sense to distinguish between ‘Levels’ of abstraction: Level0 is the party actually doing the work (the ‘Resource’), Level1 is taking the decisions (the ‘Owner’) and the Project Manager who reports the status the Level2. As long as the Level0 remains the person actually doing the work and the reporting becomes ever more ‘distinct’ from the actual doing, Levels 3 and higher might be added to reflect the various delegation levels. The highest number is reserved for the Product Owner, let’s call him L4 who specifies the Project Requirements.

These levels have a second usage as well: during the change the expert Product Owner generally is overburdened – which is the reason the Project is set up. This workload means that the Product Owner can not answer all of the questions that come out of the organization. By channeling the questions from the L0 in doing the work via the L2’s to the Expert L4, also a multiplier effect is being achieved. Simple questions can be answered immediately and only the difficult questions reach the Product Owner.

Coincidentlally, this structure partially overlaps with the RASIC-distinction: The L0 doing is  ‘Responsible’, the L1-deciding is ‘Approving/Authorizing’, the L2 needs to be Informed, the ‘Supporting’ is nothing but a differentiation of the L0-doing and the Consulting’ is nothing but the L4-Expert.

Co-dependencies

For such an organizational Project often a Staff department is the ‘Client’ or Product Owner (‘L4’). An easy pitfall for this Product Owner is that he usually is so overburdened with work coming out of the change that he does not have time for clearly specifying what exactly needs to be done, let alone writing a clear acceptance test. In practice I have noticed two prevalent ‘cop-out’-strategies. First of all, the absence of an acceptance test gives him an easy way to torpedo any project result: with no justification needed the result can be declared to be ‘substandard’. The Project never gets finished, so a good Project Manager will not allow this to happen. The second ‘cop-out’strategy is to just accept the project result and not create waves. Thus, Line Management just continues as it has done before. After completion of the Project, the Staff department can continue easily finding errors and complain about the Line. Here a co-dependency exists between the Client(‘L4’) and Project Manager which can only be tackled by general management one level higher demanding a rigorously executed acceptance test. A professional Product Owner provides a clear specification and acceptance test, but not every Project Manager is so lucky.

In case Line Management is too busy doing their regular work to take upon itself to do the additional work a Project always entails, the Project Team might be ‘forced to do the work themselves’, for which they generally lack the expertise and which results in the Line Managers not getting the additional knowledge and experience to continue the change. Here a third conspiracy-like co-dependency may develop between Line Management and Project Management: if Line Management accepts the quality of the work done by the Project Team, the Project Team meets its goals and can declare victory. Top management gets Status Reports in the green and is off everybody’s back. As of the moment the Project Team is disbanded the knowledge about the change dissipates and everything reverts back to the original state. A sure-fire way to failure in the long term.

The reader will be relieved that of course this self-defeating cycle does not occur in her own organization.