And linked to this is PRINCE2 which uses the idea of "controlled environments". There is a lot of useful stuff in PRINCE2 and in project management generally, but so long as they keep their roots buried in the decayed ground of command and control, we'll continue to see projects fail.
Let's unpack some of this.
Controlled environment
If you try to control your environment you necessarily have to limit variety. Yet as Ross Ashby clearly demonstrated around 70 years ago, if you limit variety, you "kill" it. Stafford Beer went on, in his Viable Systems Model (which is over 60 years old now) to show that if you kill variety in a system, you downgrade its ability to survive.Control as reduced variety
Let's illustrate this with a very simple example. Currently your customers contact you in a variety of ways: they may phone or write, tweet or email, or maybe even turn up in person at your HQ or stockholders' meeting. You decide to make things more efficient and install IVR ("interactive voice response" the annoying mechanism whereby you have to go through layers of automated menus on the phone before you get to speak to anyone). You also decide to only accept written communications via email and remove their address from all company advertising and web sites. Result: unhappy customers - the variety of their system is greater than the variety of the organisation, so you are cutting them off by forcing them down your more limited route.Control in viable systems
There is a different sort of control. Beer's VSM, referred to above, uses control as an embedded part of the system to ensure that the sub systems are inter-relating effectively: "the controller is part of the system under control ... not something stuck onto the system by a higher authority which then accords it managerial prerogatives. In any natural system ... the control function is spread through the architecture of the system" [1]. In very simple terms, in the VSM, the sub systems are autonomous - they can get on with their job without undue interference.To give PRINCE2 its due, quite a lot of the control it seeks to provide is of this latter sort, and the problems partly lie in the way the control part of PRINCE2 is interpreted. But as a framework it nevertheless creates an organisation that seeks to reduce variety, that is essentially a command and control framework.
Agile goes some way towards fixing control
Agile attempts to turn this on its head (and it's always worth going back to look at the Agile manifesto to remind ourselves of this). People come first. If the focus is firmly on the people you'll quickly come to realise that people are different from each other and that their needs change over time. Linear frameworks (waterfall is an example, along with PRINCE2) simply don't work well in that environment because even assuming you could get 100% correct requirements (and that's a big ask), by the time you've delivered them the requirement will have changed anyway!Central to Agile is that requirements emerge and change over time, so you have to be reactive to that. This is very much in sympathy with the VSM idea that systems are dynamic and the control mechanisms have to be adapted to that dynamism: Beer describes this as being heuristic[2].
It's the Project Board that's at fault!
I hope you'll have been thinking about project boards because this is where the problem lies. Recall Beer's contention that systemic control is "not something stuck onto the system by a higher authority which then accords it managerial prerogatives" (my emphasis), yet -- without the "not" -- this seems to describe exactly what projects boards are! As I noted at the start, PRINCE2 is borne of the command and control way of managing things that is still so pervasive. But in a viable system this simply does not work.Peter Scholtes, a great follower of W. Edwards Deming, calls command and control "train wreck management" after the incident in 1841 (a train crash) that led to the start of this way of managing things [3]. Like Beer, he sees systems thinking as the way forward and describes the leadership model that engages with this [4].
In the next post I will explore how I think we can use Beer's VSM and Scholtes' systems thinking as a different model for project control, rather than project management.
[1] Beer, S. (1981) Brain of the Firm, 2nd Ed, p. 25
[2] ibid pp. 54-57
[3] Scholtes, P.R. (1998) The Leader's Handbook, p. 2
[4] ibid pp. 19-49
No comments:
Post a Comment