Software projects can take on a life of their own. And unlike cars or buildings, software is infinitely changeable. So people tend to want to make changes, run test code before it’s ready, and “worst of all”, add features. So how do you manage a software team? Read on …
The simple answer is to be meningeal about focus. Focus, focus, focus. That’s the line to defend. If people start to drift (and they will), use some kind of re-focusing until the team is back on task.
Tip number one – start with the goal in mind.
Every software project has one main goal – to deliver a set of benefits or values for the end user. Keeping that goal visible and in an easy to remember form, makes communicating that goal easy. The clearest goal means less arguments and meetings, less bickering over features and less change of ideas. While we all like creativity, sometimes more ideas can kill “getting it done.” That reminds me how much I need to write something on procrastination!
By reducing the project goal to a set of simple tasks, it is easy to stay on track.
Tip two – simplify.
The Einstein Principle – “A scientific theory should be as simple as possible, but no simpler.” This also works in project management. Take each task and reduce it to the simplest deliverable that could satisfy the overall goal. Doing that means the increase your chances to get this version of the software done, putting extra features into the next version of the software.
As it turns out, having a minimal version of software in testing is better than waiting years to release the fully developed version. The simple version allows some return and real feedback – often killing other feature ideas. And, as I’ve said, too many ideas can stop a project dead.
Tip three – double your planning time.
In the book Alpha Project Managers: What the Top 2% Know That Everyone Else Does Not, the author looked at 800 project managers and distilled what the best did. Interestingly, the top project managers spend more time planning. In fact, double, while cutting time spent on other areas.
Here are the author’s findings, in case you’re curious:
- Alphas respond to fewer emails/day and spend less time in meetings than non-alphas, yet people rated them as being more responsive than non-alphas.
- Alphas establish explicit communication expectations, and adhere to them stringently.
- Alphas sent much shorter communications than their non-alpha peers.
- Alphas spent twice as much time in the planning phase of their projects than did non-alphas.
- Alphas used informal networks to get things done much more often than non-alphas (who stuck to formal channels).
- Alphas were much more aware or how their bosses were being measured (ROI, etc.) than non-alphas.
Tip number four – hold people accountable.
As strange as it may seem, but enforcing people to meet their deadlines reduces distraction. The team, project and each individual won’t have time to stray, if they are expected to meet deadlines. This kind of pressure causes people to focus and that drains people of some energy to run amok.
Also, when you’re personally accountable, you take ownership of situations that you’re involved in. You see them through, and you take responsibility for what happens – good or bad. You don’t blame others if things go wrong. Instead, you do your best to make things right. In the workplace, accountability can go beyond your own tasks. For example, you may be held accountable for the actions of your team.
The final tip – release something.
Execution is what differentiates a good software team from a lousy right?
Well, that depends on what you call execution. In Geoff Moore’s third book, Inside the Tornado, he explains how successful software companies, “Just ship.
Don’t tinker.” This is, they get the next version out the door fast, with few bugs, sure. But they get it out without all the half done features.
If you follow these principals, you’ll be able to manage a software project to completion. Software is different than hard, packaged goods. Paradoxically, since software is so easy to change, managing these projects is actually harder.
References I mentioned above: