There are many different ways to schedule and plan work. Some are task based, priority based, time based, or - what most PMO organizations prefer – effort based. Effort based planning is based on using the amount of effort or time each task takes to create a bottoms up approach to planning. Anyone who has used MS Project is familiar with effort based planning. Essentially you take a list of tasks to complete work, assign them an order (1 before 3, 2 before 9, 4 before 1, etc) and the amount of time it takes to complete them, and whammy you have your schedule based on the start date you enter. This sounds like a good approach. The problems arise however in the details. After more than a year in consulting, planning is good, but the Devil Really is in the Details.
The biggest problem with effort based planning – at least with a development project – is that you actually never know all of the tasks or the effort it takes to complete them. A good example of this is that a developer may tell you a modification will take 35 hours and instead it only take 5, while other days they will tell you 5 and it will take 35 hours. So to make the plan you need to know how long tasks take but this is always going to be a best guess scenario. Second more tasks will present themselves as soon as you start working on a project. For instance the software vendor may tell you something is automated but then you find that it is only automated in certain cases. Now someone has the task to once or twice a week update or validate configuration tables. This throws a monkey into the wrench for sure.
The next biggest problem with this approach is granularity. How detailed do you want the plan. Personally I think giving people blocks of time is more effective than planning to the hour. Unfortunately this is harder to measure to if you are measuring the effort. In the case of testing there should be a certain number of test cases for a team to accomplish any day. If they miss some they are behind if they complete some extra they are ahead. But many clients want to know by the hour when things will get done. Well just like with programmers this is nearly impossible you will always be ahead or behind. Some tests will take minutes others days. So a lot of effort can be put into developing list of all tasks and dependency involved and planning each of these tasks based on effort down to the minute, but what does it mean. As soon as one thing takes longer than it should the plan is worthless. It just moves forward into the future.
The real issue with this is you spend all your time planning and no time executing. Even when you are behind you keep reworking the schedule. The final deadline isn’t moving so the only thing to do is make people work harder and longer. However if the PMO isn’t strong enough this never happens. In fact they just keep reworking the schedule and report on-time and on-budget. Eventually the back log will catch up though and the project will be in real trouble.
Now personally I think taking a harder line on smaller milestones and letting the various teams worry about the details is a better approach then planning to the detail and never push issues to closure. So if 20 tests must be run by the end of the week… well… no one goes home for the week until all 20 are run and passed. If the development is holding up completion of the process… well…no one goes home that night until it is done. No amount of planning is going to get the work done; only time spent doing the work will get the work done! I think this is why some many projects go over budget and take so long. The management is not willing to step up to the fact that things are behind, that the plans can only be rough guides, and that eventually to get done there has to be people working extra to get tasks done. Effort based planning, especially down to a daily workload, is really a bunch of BS. You have to plan based on when things have to be done and make people hit those deadlines regardless of what needs to be completed. If management isn’t will to do this projects will never make deadlines.
To go along with this management also needs to know they have to give the employees a reason to pull harder and get things accomplished. So beyond realistic planning, taking a hard line on deadlines, people must get something personally from the project work, but that is a topic for another time.
No comments:
Post a Comment