Whatever agile methodologies may say about “plug and play” teams, in an increasingly complex working world it is no longer feasible for one person to have the skills necessary to undertake all of their colleagues’ activities. While an engineer in Henry Ford’s day could rise through the ranks to become a project manager able to set the work and practices for junior employees, since lean manufacturing practices were introduced at Toyota in the 1950’s responsibility has been steadily devolved to individual team members as work has become more specialised. Thus, over time, it has become increasingly difficult for any one person to hold all of the requisite knowledge. And in the rare cases where this has been possible, it has proven very hard to replicate any kind of success when that person is no longer around (Steve Jobs and Apple spring to mind).
So what does this mean for meddling management and that pesky project manager? Well, when people’s skills are a combination of skills and creativity learned and practiced over many years (which is particularly true in a technical environment), micromanagement is no longer an option. This is a bit of a blow for the traditional project manager. Perhaps the biggest challenge faced when starting a new endeavour is figuring out how to reduce a multitude of possible paths and the associated plethora of unknowns to manageable proportions, and the traditional “tried and tested” approach to get a handle on the sheer vastness of a new project is to create a Gantt chart in the hope that a detailed plan will bring about some semblance of control. The trouble is that the people best placed to undertake project planning are those that have the appropriate skills to enable them to estimate activities and durations and then to actually execute the plan, i.e. the project team, and the moment we push the planning process out to them the traditional command and control approach collapses.
So how should we go about planning projects in this new world? We can hardly expect (or want) team members to produce separate schedules for their own activities which are then magically consolidated into one over-arching plan. Anyway, in reality there is really no reason at all to perform this detailed planning as long as team members are trusted to apply their own skills and experience in figuring out the best way to attack a project and produce the requested deliverables. All the project manager need actually do is maintain a prioritised “list of stuff” (called the “product backlog” in Scrum or “prioritised requirements list” in DSDM Atern) in order to control and prioritise delivery and reduce a seemingly impossible endeavour into manageable, logical chunks. This simple list may then be regularly reviewed and easily shuffled as the project progresses in response to new knowledge gained from functionality created during the project process.
In his book the Checklist Manifesto, Atul Gawande proposes that “the volume and complexity of what we know has exceeded our individual ability to deliver its benefits correctly, safely, or reliably. Knowledge has both saved us and burdened us.”
His response to this dilemma is for us to create a simple and targeted checklist when undertaking any complex endeavour. In principle this means that we make a simple list, get on with the work, and then regularly take a view of where we are as a result. Which is just what Agile methodologies suggest we do when dealing with complexity in project undertakings. Whether for pre-flight checks, heart surgery, or IT projects, the humble list is the tool for the 21st Century.
