At the company I work for (which will continue to remain nameless to protect the innocent), we have what I consider to be an incredibly odd problem within our development cycle.
My latest task is to identify problems within our project lifecycle that can cause bottlenecks in the delivery process. Normally this would point to internal inefficiencies: insufficient collaborative tools, technical problems, or misunderstanding of functional/business/QOS requirements.
it turns out we do pretty well here (we have our share of problems, many of which have been relieved with my recent rollout of Team Foundation Server). Where we get nailed is, interestingly, when clients fade away from the project.
That's right - clients who make considerable investment in design and development services simply lose sight of the project and disappear from view. It is not unusual for clients to go over a month without returning emails or telephone calls. Of course, when they DO resurface, they are shocked and amazed to learn that their project has not moved forward (either from lack of feedback or some dependent deliverable that has not made it over to us). And that's when the bad feelings arise.
In thinking about this, I started to analyze the things we are doing, within the context of some initiatives we've implemented to keep the client engaged.
- We provide 24/7 development site access. Clients can view progress in real time, and they can "touch and feel" the project with feedback opportunities along the way.
- We provide weekly status reports describing the project state, dependencies not delivered, anticipated risks, and evolving scenarios that may complicate the schedule.
- Phone calls and emails are made at least once a week seeking updates on missing deliverables.
- A financial penalty is applied if a project is stalled because of missing client interaction or deliverable for at least 2 weeks.
Its this last item that I have the hardest time with, because of the greater ill will it creates for the customer/client. Is the new perception going to ruin the current or future business relationship? Its hard to say, but all signs point to yes.
We have had one customer who basically told me "I'll call you when I'm ready to move on this". He disappeared for a year, after investing eight thousand dollars in his project. He resurfaced, profusely apologetic, looking to start again, with a code base and requirements over a year old. Reluctantly we did so, and he disappeared again for another four months. This time we stopped the project and explained that we were very behind, there were a large number of dated unknowns, and we could not move without re-speccing the project, requiring authorization for a change order. He balked and accused us of trying to unfairly increase project costs. This customer completely ignored the concept of the worth of his dollar a year ago, combined with the intrinsic costs of rekicking a project, among other things, and expected the same project to be delivered within the same cost.
This is a true story, and we have other customers who have disappeared (not for as long). It presents a customer relations and project management nightmare. But it is impossible to convey the hidden costs overruns on projects to the customer, especially when there is a semi-fixed cost estimate involved.
Changing the process to incorporate more milestones can help, but only partially. This is because once a milestone is reached, and momentum is generated, clients can get a false sense of project status. It also blows up the estimate model to some degree, since revisions and iterations in the same milestone period can give the appearance of inflated time (especially when using agile methods, notoriously known for increasing scope creep). It really isn't - its adaptation based on client input - but the estimate gives an impression of a fixed cost, so it is difficult to justify why other features have to be dropped over the course of a timeline and budget.
In any case, it is a problem with no easy answer. Usually it is the client who does the browbeating. I have never worked in a scenario where those roles are reversed.