Are we doing good?
The key to good project management is that, often, the client see progress and the developer get compensated.
How often? Many small projects move slowly, right? I would argue that, the smaller the project, the faster we should see improvements.
- For a SME (small or medium enterprise), 240 to 360 man-hours may cover 4 to 8 stories.
- For a small project with a single programmer working part time, 4 to 12 hours may cover a single mini story.
Not convinced? Please consider the following:
- Small projects are... smaller. Features should be simpler and easier to implement.
- Many small projects build on top of existing functionality (think "asset store"). While changes to existing source are time consuming, more often than not such changes are small and do not (should) not impact existing structures.
- Small stakeholders shouldn't commit over large amounts. No more than you should gamble your house before your mortgage is paid for.
Is something wrong with our project?
The following clearly indicates that something needs fixing:
- The software isn't working. If the software isn't working on the client's box, at least it should work on the developer's (who can demonstrate progress by uploading a video)
- The developer do not know what they are supposed to do.
- The client do not know what the developer are doing.
- The client and the developer disagree about the result.
I'm not suggesting that you micro-manage your project. If the developer get paid regularly, and the client can see visible improvements, you are doing just fine. Otherwise, read on.
How to manage a small project?
I will assume that you are working on a small project if you put 8 to 24 man hours per week into development. In short:
- The developer and the client must agree on deliverables. Agree on 2 to 6 deliverables per 24 hours period.
- Describe deliverables using stories. A story is a common-sense description of a feature which adds value to the software.
- If possible, give a heads up to your client when you have completed a story.
user stories
Problems and solutions
Developer: "I need a framework"
Read elsewhere about Big Design Upfront.
Although you may feel that a framework
I don't understand what the developer are doing
Explain to your developer that you pay for visible progress. Refuse to pay for technical stuff that you don't understand.
Irrelevant to perceived usefulness, some features are expensive to implement. This stuff should average itself over time. You can appreciate this on a velocity chart.
Velocity Chart
When in doubt, you can ask advice from another developer; if you feel that work is slow, you can also get another developer onboard. Adding a person to a project is less risky than firing your developer outright. After all, they may be struggling with genuinely tricky stuff.
I don't understand what the client want me to do right now
Some clients have a core vision / general objective in mind but may not know how to achieve their goal, or may feel unsure about where to start.
Don't be uptight. Make your own task list and show it to your client. In most cases, small clients feel happy to see the burden of project management lifted off their shoulders.
The client are unwilling to pay until the software is 'complete'
Explain to your client that you expect a compensation for work done, and give them means to monitor progress. If this doesn't satisfy them, you don't have to work for them.
The client will pay after reviewing the code
Do not agree to this. Agree to small deliverables, so your client can review the code after they pay for it.
90% of the software out there, including software used in ATMs, rockets, the power grid and medical equipment, isn't "good software".
Conclusion
In this article I shared my experience working on small projects. I hope that this will be useful to you and wish you success in your endeavours.
No comments:
Post a Comment