In this post I wanted to share some of the magic tricks I’ve picked up over the years that can help turn even the worst projects into golden triumphs.  In this day of software development and virtual worlds we can achieve what the original Alchemists could only dream off – we can turn lead into gold.

Firstly, don’t bother with trying to estimate the size of a project – it will be wrong anyway.  Simply pick a date that suits you and convince everyone that that date is the end of the project.  If you are finding it hard to persuade people that this is a winning start to a project, try pointing them to information about the “Project Management Triangle”, such as this article on Wikipedia.  Even better, simply explain that as part of the project management triangle you can achieve any timescale by moving the other 2 sides of the triangle – cost and scope. The trick here is to win the argument on timescales without compromising the amount of people on the project (cost) and what you wish to achieve (scope).

If your team still won’t accept being told when the project must be finished then maybe they are particularly bright or actually read up on the project management triangle as you suggested.  In this case, you may need to provide a little more justification for your timescales, which means producing a project plan with tasks and estimates in it.  Some people recommend asking the person who is going to be performing the work how long they think it will take to complete.  In his article on Evidence Based Scheduling Joel Spolsky notes

“Only the programmer doing the work can create the estimate. Any system where management writes a schedule and hands it off to programmers is doomed to fail. Only the programmer who is going to implement a feature can figure out what steps they will need to take to implement that feature.”

However, unlike Joel’s usually sound advice, I find asking the developer to estimate the work just distracts them from actually doing their main task of writing software.  After all, you are the manager of the team, dealing with schedules is your domain.  So, crank open your favourite project planning tool – Microsoft Project is highly recommended, and start filling in some tasks with some estimates.   You’ll probably find that based on the tasks you can come up with and your first guess on how long those tasks will take that your project is not going to be ready when you want it to be.  Don’t let that put you off.  Simply keep adjusting tasks, remove a few, reduce the duration of a few and manipulate away until you have the date you were looking for.  Remember, this is why you are paid the big bucks – scheduling is hard and requires tough decisions to be made to reach the target date.

So, we now have the first steps towards a golden project.  We have a suitable end date that will make everyone happy, and we may also have a plan that proves the date is realistic.

Now we need to make sure the developers stick to the plan.  After all you didn’t spend all that time making it look pretty for it to be ignored.  Here’s the next tip – status meetings.  Weekly updates where the whole team gets together and sits around a table discussing progress with you.  I find it works best if you ask each person in turn for their status and force the rest of the team to listen.  This is a great way to get honest feedback and build team spirit.  It also keeps the pressure on everyone to provide positive feedback – no-one wants to be the person bringing bad news to the meeting and so your milestones will pass by on time all the time.  Don’t let these people put you off when they suggest the round-table meeting as being a waste of time:

• Johanna Rothman – Creating a Learning Culture
• Why your meetings suck!

Ok, so we all know that software projects slip.  Developers just aren’t as motivated as Sales guys when it comes to targets, so sometimes they need a helping hand.  You have two choices here – a carrot or a stick.  The carrot works in Sales so it must also work for developers – offer them a bonus.  That one is easy, finish on time and you give the team a bonus.  However, that can be a little expensive, especially if you need to do it on every project, so you could also try the stick approach.  Who doesn’t work harder when they’ve been shouted at?

Right, so we are nearly there.  Here’s a quick recap on what we have so far:

1. A winning plan or end date
2. Great estimates
3. Weekly status updates that show that the project’s on track
4. Bonuses for finishing on time or the threat of a good boot up the backside to keep the motivation high

So, here’s my final piece of advise.  If you are really unlucky and your project is still not progressing as you’d like (or you’re just aiming for the stars and want to bring your project in early) then you can try this final killer tip – Overtime.  You can accomplish almost anything with Overtime – it’s your time to use, as and when you require it.  If your team comes up with an extra task that you somehow overlooked in your plan – simply get it done in overtime.  If the team starts complaining about the schedule point out how many extra hours there are outside of the 9 till 5 and during the weekend.  Don’t be afraid to tell them how hard you work and the extra hours you put in answering phone calls, writing emails and fiddling with the plan.  Don’t let them tell you that working more than 35 to 40 hours a week is unproductive – that couldn’t possibly be true – more hours means more work gets done, after all you have the plan in MS Project and if you put in more hours the progress moves up a few more percent.

For anyone who’s got this far and not found any irony in what I’ve written, I’ll be adding a new post soon that explains more of the thoughts behind “Project Management Alchemy”.