From long experience as a programmer, and later as an applications development manager and as a project and a programme manager, I have been obliged to study and apply/devise methods of dealing with the waterfall of incoming change requests and new development requests.
The main issue is nearly always "Resources". In fact, a ROT (rule-of-thumb) in project management is:
Unless you have resources committed to the project, don't bother to plan for it.
That's because
hypothetical plans do not help you get a job done. Furthermore, they can induce a subconscious feeling of pressure that the potential
future that they predict is something that must now magically be achieved. It is of course
irrational to believe that you can or must achieve an imaginary or phantasmagorical future state.
Que sera sera. It is dreaming, yet that is precisely the thinking trap that many people fall into (cf. Deming's 14-point philosophy re targets and MBO).
I found this simple truth difficult to grasp when I first heard Deming lecturing about it in a seminar, because it went quite against: my training and indoctrination; my
belief; and the received wisdom on the matter.
Hypothetical plans are at best good for time/cost estimating, but are useless for pragmatic work/project planning.
A pragmatic work/project plan states how you
actually intend to set about doing something. (That does
not predict that you will achieve it.) Hence the ROT. Before you can set about doing something, you generally need to have a clear picture of the resources you actually have committed to do the work.
Always, your resources to deal with the potentially infinite waterfall are finite, so you have to prioritise the queue to help guide you as to how best to go about "eating the elephant". You then allocate the prioritised work tasks to the resources committed to doing it. However, if your resources can only give a spotty or part-time effort without definite commitment, (say) because they have already been given other/higher priority work to do, then the plan fails the ROT test - i.e., you don't/can't have a pragmatic/workable project plan, because the resources cannot be committed to it (QED).
In that spreadsheet - which I did quite a while back - I provided a prototype of a suggested approach for establishing and organising a group-accessible and documented
queue of prioritised user change requests (which could include bug changes also).
That's all it is - a queue.Nowhere does (or should) that spreadsheet say "When will this work be started/completed?" This is deliberate. It would be irrational to suppose a date because (in
@mouser's case) -
the resources cannot be committed to it (QED).
So, in such a situation, far from putting any pressure on anyone (the developer or anyone else), the queue could do quite the reverse. It could
relieve any subconscious/conscious pressure from phantasmagorical deadlines, leaving you free to focus your now less cluttered/confused attention on what requests/bugs need to be addressed first, given their priority. So
priority becomes the issue - not the now irrelevant "when".
In the spreadsheet, the developer could take 3 factors to assess the queue of change requests:
- 1. The priority:
A = Mandatory ("must have").
B = Highly desirable.
C = Nice-to-have.
- 2. The reach of effect:
Estimate of of users who potentially could and would make use of this.
- 3. Relative ease: The ease/time that the developer imagines would be achievable for implementation of a change to meet a given requirement. (It is not recommended that this ever be stated as a commitment.)
Of course, it is up to the developer, but I would recommend a Kepner-Tregoe approach where you go for a points-rating of these 3 (or other relevant) factors. They are all pretty subjective, so taking the approach of (say) ascribing a value/weight to each and then adding or multiplying them together could give you a useful semi-rational outcome (a numeric score). This might be the best (most rational) that you are likely to be able to achieve under the circumstances.
You then treat this as a task order - you pick off the work in the order of highest points-score first, as and when you have time to put some work into it.
