Is your working week mapped out in advance with a detailed to-do list and discrete meeting appointments in your calendar? Probably, but how about longer term? A task list for the next twelve months is likely to be much more of an overview including summarised entries such as learning a programming language or taking a management qualification. And while your diary may hold a number of recurrent meetings, for example an update every three weeks with your project sponsor, it just isn’t going to be possible to predict the majority of the ad-hoc meetings that you will end up attending unless you know exactly what you are going to be doing for the foreseeable future. If you are an author, for example, you can pretty much plan what every day will look like as you have a defined aim and are working pretty much on your own so this can be done, but in a project team role you are dealing with people and complexity and just won’t have the luxury of being so precise.
So why is it then that a traditional project always starts with an impossible mapping of detailed tasks for the duration of the undertaking? This just isn’t how people (or indeed the future) work! In the same way that embracing social media can boost project communications (as people are using these tools in their personal lives anyway so we should make use of them), we should always look to control our projects in ways that align with the methods people actually use do the work, i.e. with short-term detailed tasks and targets, and longer-term headline aims. Plans are essential for a controlled delivery, but only if they are both realistic and current. If you create and maintain impossibly detailed plans for anything other than your next iteration, aren’t you just wasting time planning for planning’s sake and running the risk of your sponsor starting to believe the rubbish on your pretty Gantt chart?
But how is it possible to establish control if we don’t have detailed tasks mapped out in advance? Well, it really comes down to providing a framework that allows a high-performing team to emerge, and then trusting the team to plan, manage, and deliver their own work – in other words: set up the process; let the team go; get out of the way! The key difference between waterfall and lean methodologies is actually one of focus: traditional managers focus on a plan, whereas agile practitioners focus on their people. I believe that the project manager’s sole responsibility is one of ownership, maintenance, and evolution of the way a project is run (see Project Management, RIP), not the micromanagement of an individual team member’s activities. One of the aspects of this new role definition is to protect the team from unreasonable interference, particularly if they are working on intense, client-driven iterations in an agile environment (we can’t expect progress if all customers are allowed immediate, direct access to the solution developers, so as PM you can expect to find yourself spending a fair amount of time keeping the “wolves from the door”). But an even more important result of this definition is that what people do and the schedule that they work to is not for you but for them to decide. In other words, we must aim to promote and create a self-governing team who have responsibility for their own planning. In an agile approach such as Scrum, this takes the form of a planning meeting every few weeks (a period called the “Sprint”) where the business representative (“Product Owner”) sets out her priorities and the team respond with how much they think they can do in the next iteration. In this way, your people are always working on the most current and important requirements using a detailed short-term plan of their own devising which they create and control. This also frees the project manager from the drudgery of maintaining a long-term detailed plan which is subject to change on an almost daily basis.
I am not suggesting that that there should be a complete absence of any overarching strategic direction. Indeed, methodologies such as DSDM Atern suggest the maintenance of a summarised delivery and deployment plan that maps out the milestones and overall aim of all iterations in an endeavour so that scope is controlled and the customer gets what they need at a defined time in the future. Contingency is then built in through prioritising requirements with the business, with functionality delivered in a prioritised order and the hitting of milestone dates all but guaranteed; remember, on an agile project it is OK to deliver a partial solution as long as it delivers the most important (working) functionality as defined by the business.
Work is about more than the creation of stuff. Forget shareholder value and take a leaf out of Richard Branson’s book: treat your people well and give them an environment in which to shine and they may just reward you and your customers.
