A Place for Traditional Project Planning?
In this age of agility and ‘getting things done’ over ‘talking about getting things done’, it’s often asked if there is still a place for traditional planning, particularly at the outset of a project or consulting engagement. For us, the answer is yes.
We find it particularly useful to commission each project or consulting engagement with a work plan. Our work plans are documents not too dissimilar in content from project charters or project statements that one might find in any well structured, process oriented environment. We call ours a “work plan” largely for connotational reasons. Yes, we do want to plan but only to the extent of understanding and conveying what work needs to be performed to achieve what outcomes or deliverables over what period of time for what budget.
There’s still a heavy focus in our work plans on ‘getting things done’. We shoot for the minimal amount of information needed to crisply and clearly convey the plan of attack to ensure that everybody is on board with that plan. And that applies not only to our customer stakeholders but to our own internal team as well. The process of developing the work plan helps bring our own team into alignment on the work that needs to be done, over what time and what expense allowing them to forge ahead when it comes to Sprint Planning and Development.
Project charters and project statements can fall prey to ‘talking about getting things done’, articulating ad nauseam every minute dimension of a project to the point that it takes weeks to develop, serving only to delay what is of true value, execution. And they become so voluminous that no one gets through them let alone understand them.
Our work plans tend to be no more than 10 pages long and take no more than 2-3 days to develop. The very same week that we kick-off a project, we will have developed and agreed the work plan, enabling us to move very quickly into execution with everyone on the same page in terms of the way forward.
Once the work plan is complete, we extract the relevant information and enter it into our online work management systems for on-going tracking and monitoring. We never come back to the document. That becomes shelf-ware. Instead, we rely upon the status, discussions and decisions recorded in our online work management systems to convey the state and direction of a project at any given time.
For example, we’ll extract the work schedule from the work plan and enter that into the calendar in Basecamp (that may then become tasks in Tick, which we use to track time when operating under a time and material arrangement). We’ll then update the Calendar in Basecamp (and Tasks in Tick) as necessary throughout the project, removing the need for us to ‘issue’ a new project schedule. The project schedule is inherently issued as it is updated in Basecamp and it’s there for everyone to see real time, when and as needed.
Similarly, we’ll extract information relating to work breakdown, in particular the features of the App to be worked on, and enter that into Trello, which we use as an online Scrum board. Again, as changes occur to the feature composition of an App, we simply reflect that in Trello as opposed to going back and updating our original work plan.
In summary, we believe there is still a place for traditional planning in the age of agility particular to help kick start a project or consulting engagement. Once started, however, we then move into a more dynamic mode of planning (e.g. sprint planning) and tracking and monitoring of progress.
