All of these should be done together with the client, or in close coordination with them.
This is as much design phase as planning phase
No dates and deadlines here, only amount of work
Releases are extremely important as they shall mark invoicable events!
The result of all the points above
Darren: it says that milestones are preferably one month but no longer than 2 months. For me even one month could be too long. I realise that later on (5.4.1) you talk about weekly checks for - I assume - internal targets but are these connected together? I have started to use “Releases” instead of milestones and each release has a new requirement implemented. The way I look at it is that each release builds on the previous, so instead of trying to figure out what is “independent” of others, I try and create a dependency chart and use that as my design timeline. For example one project I’m working on requires a very strict directory/file structure, so this had to be implemented before I could start on the actual data storage.
Darren “Take into account other projects”. I find this quite an interesting statement, as how do you decide which project has priority? You said that you have 3 smaller projects that have got behind due to your work on the 2 bigger ones, was this a conscious decision or did it just happen? Do you think that psychologically it would be better to focus on the smaller ones and get them finished, allowing you to then focus on the bigger ones? This obviously depends on customers etc. but what if they were all as important and all had the same deadline, what would you do?
I was rather talking about the planning phase, the time when we’re coming up with a timeline proposal for the customer. We need to consider not only that resources can be already reserved for other projects, but we also need to listen to our gut feeling about possible collisions with other project work down the road etc.
So you mean during project execution, when other things get moved and suddenly everything collides? We rate our customers, in terms of revenue, earnings, payment arrangements and payment moral, technical level (interesting high-level work or boring support), potential (how much work will we get in the future) and “overall feeling“ (yes, a soft fact, on intention!). Projects then get rated in a similar way, plus how urgent is a given project, plus how positively or negatively will pushing back affect our solvency. Coming back to our current status, the two large projects are the most important, and there’s a lot depending on our software (in one case, a rocket production line, in the other a newly built test area where the building alone cost 30 Mio Euros - both make me feel a little uneasy at times). Two of the three smallish projects could be pushed back without much worry, so yes, this was easily and consciously decided.
Richard Work Packages - Similar to an AGILE delivery process. Nice. Always good for measuring progress too, and disseminating elements to third parties.
Richard Work Estimation - Pessimistically? Do you mean conservatively, in order to ensure you still have a buffer in there for when you miss or underestimate something? When you've done something before, in a previous project, feel free to capture the time it took to develop and use that as a best estimate. In my estimates I usually a global contingency for the unforeseen, and explain the reasons to the customer. Especially for R&D type work.
I adopted the word „pessimistic“ after discussing this with Steve Watts, my point being something along the lines of „…realistic, not pessimistic“. Please take a look at https://forums.ni.com/t5/Random-Ramblings-on-LabVIEW/A-Pessimistic-Approach-to-Software-Design/ba-p/3673116 and the comments, and let me know if that changes your feeling?
Richard Milestones - Interesting. I agree with milestones as you describe them, although not necessarily as billing opportunities. For the customer, the billing is often related to tangible achievements and for you it's about regular financial income. Although these can coincide nicely, often you have to be a bit flexible. My invoice milestones are often 1. Immediate for hardware cost coverage, 2. Upon delivery of software/hardware solution, 3. Final invoice on successful commissioning and site acceptance testing (often this part takes ages, and sometimes doesn't ever happen due to customer problems, so make it a small component).
Richard Risks - Consider the risks presented by the customer foremost. You can often conceal or mitigate your own risks as they're largely under your control (sickness, holiday, priority balancing). But the customer risks (their hardware prototype fails, they financially struggle, they shelve the project etc.) can be really serious when they affect you - often they won't care about how this affects you, and if you don't cover yourself up front then there's no renegotiation later when the s### hits the fan
Malcolm I do think a more organised approach is absolutely essential and the first thing to realise is that a project is not just coding for 40 hours a week. Perhaps you (we) should start with an assumption that we only code for 20 hours a week and the rest is some form of project management or testing.
Malcolm I sit on the fence about billing. I take Richard's point about monthly billing being good for cashflow, but that can look like you are operating as a contractor. I think a move towards milestone billing makes you look like a more 'grown up' company. I also agree with Richard's 'hardware costs up front' and perhaps I would add 'paid-for feasibility study' up front as well. I think this should aim to be about 10% of the final project costs and covers requirements capture and test and commissioning requirements.