July 17, 2015
Posted by on
Project delivery in the IT space is a fun job. You get to do interesting things, usually no two things are exactly the same and in the process get to play with technology. Life couldn’t be better. That is until you run into some oddities. Agile methods have not been everyone’s cup of tea. Ambiguity is the enemy of most bureaucratic environments. Before committing to any spends, they want assurances in triplicate exactly what they would get for the project, when, and in what manner. By definition killing any agility.
What is interesting is that some of these organisations appear to be embracing Agile, but not because they want continuous improvement, or are looking to deal with ambiguity differently. They have found the dreaded requirements analysis phase of a waterfall project does not necessarily capture the requirements correctly, and consequently deliveries do not meet the outcome they set out to. Pushing that detail to be worked through in an Agile development method makes perfect sense.
Pushing the resolution of ambiguity later in the development phase means at the project initiation that ambiguity still remains. So any contracting for those services can only give you an estimate to a particular level of detail. What I find in many cases is there is little room for ambiguity when contracting for those services. The bean counters still want to know exactly what you will deliver, when, and how – so when the auditors turn up, they can show a clean bill of health.
As IT practitioners we have done a good job of convincing organisations of the benefits of Agile deliveries. However, we are yet to convince procurement that effort estimation is relative to the ambiguity that has been clarified. Wherever bureaucracy is involved, there appears to be a mismatch of expectations. It is not helped by IT companies willing to do business sometimes ignore their practitioners to take such projects and perpetuate this expectation.
What are you finding out there? Is this the norm or the anomaly?
Image credit: smokejumperstrategy.com
June 25, 2011
Posted by on
In every organisation I have worked on, there is a constant need to review priority of work at regular intervals. There is pressure to show progress. If one is required to deliver three different items, they are constantly under pressure to show progress on all three. Your stakeholders start getting nervous seeing no progress in some tasks. Other times as a Project Manager, we fall into the trap of starting many tasks thinking it will help us deliver quicker. Becasue of this pressure there is a huge temptation to make a start on all three before actually delivering on any of the. This is a recipe for delaying the delivery for all three.
Regardless of your deadlines, the work required to produce your items are no less, whichever order you do it. Let me illustrate this. Suppose someone has three tasks to deliver – that each take two days to deliver. If they are concentrating on one task at a time, this is the timeline that they will achieve completion of all three.
If you now try to show some progress on all three tasks, then the profile will be
Now compare at which point each of tasks A, B and C finish. By multi-tasking all you have achieve is to delay tasks A and B, while C finishes at the same time. In effect, that too is a folly. In reality, when someone is switching tasks in the middle of another, there is always time lost to recover from where they left off. In this case, a three day gap between leaving the task and picking it up again is likely to cause all three tasks finishing later.
So next time there is pressure on you to release one of your developers (or for that matter any project discipline, even non IT), for a short period of time, consider if that is really likely to achieve delivery any sooner; or are you simply falling into the same trap.
It pays to have your people focused on getting a single task finished and then starting another.
May 21, 2011
Posted by on
A brief hiatus in posts, as I was busy with our client conference. During the conference, I was discussing with a contemporary the thorny issue of managing scope and the challenge of keeping stakeholders happy. While there are plenty of material out there regarding good approaches to control scope, I find not many address that in conjunction with managing stakeholders. Read more of this post