Does the software project you’re currently working on have a plan? It doesn’t have to be an elaborate gantt chart — frankly, gantt charts are pretty worthless though they force us to think through a variety of project issues. It doesn’t have to be a massive missive either — no one reads those things anyway.
A project plan can be as simple as a list of things to do — preferably prioritized — and a target completion date — preferably with a few interim milestones. Of course, a plan needs some thought and analysis. It has to be defensible should someone challenge its contents. If it can’t be defended, it’s not a plan, it’s just a guess.
If there is no plan — not even a guess — the project is operating with an illusion. Maybe a feature will make it into the release and maybe it won’t. Maybe a target date will be met and maybe it won’t. It’s surprising that many projects don’t even have basic project plans — they are operating under illusions.
Here are a small number of basic questions that every software project team should be able to answer. Can your team answer them?
- What value will this project deliver to the business?
- What are the primary goals of the project?
- Who needs to be involved as part of the project team?
- What are the constraints on the project team?
- What will success look like?
- When does the work need to be completed?
- What major risks or challenges does the team face?
- Does the software need to integrate with any other systems?
- Is the team dependent on anyone outside the team or outside the company?
- Who are the primary users of the software?
This is pretty basic stuff yet many software project teams don’t have the answers. Don’t operate with guesses and illusions. Put together a basic plan.
And one more thing — allow the plan to change as you and the team learn more about the problem and solution spaces. You want to be agile, right?
photo credit: williamcromar via photopin cc