Credit: Legal Terminology
As someone often called upon to be expert witness in court trials and arbitrations about the best practices in agile project management, I’ve been witness to any number of blunders by clients and consulting firms alike. My last column tackled the ways clients can ensure bad, even legal outcomes for their projects.
Now it’s time to shine a spotlight on the worst practices for agile project management consultants.
10. Use ambiguous wording in the SOW
You want to win this thing, don’t you? Euphemisms sell. So itemize things like crazy, using words that sound important but commit you to nothing. Make sure that the wording in the Statement of Work (SOW) can be interpreted at least two ways, using jargon and concepts that are open to debate. Don’t put in “fences” that clearly demarcate “in” versus “out” of scope.
9. Never memorialize phone calls, discussions, meeting topics, conclusions and decisions made with "emails to file"
Everybody hates to write, so don’t require your team members to document discussions, decisions, provisos or verbal warnings. Agile doesn’t say much about documentation, so just leave the requirements and process details as incomplete spreadsheets and terse story-cards. After all, nobody could possibly misinterpret those two years later in court.
8. Assume that the client understands Agile and inherent risks
We’re all in IT here, so of course the client understands the implications of agile work and knows about the risks inherent in their project. Particularly the ones involving interdependencies, integration, data migration and custom coding. Of course they do, even though they’ve never done a cloud or agile project before. So you don’t need to brief the executives about expectations, guide their project lead or add explicit circuit breakers in the project plan.
7. Let the client blur fixed price and time and materials
The client needs a fixed price so he can manage to a budget. You need some wiggle room. So you bid time and materials, but end up with time and materials with a budget cap – the best of both worlds! The client thinks they’re going to get everything they want (without having actually specified any of it in detail), and there’s no chance that you’ve underestimated the effort.
6. Let scope creep
Now that we’ve got No. 7 under control, we can just let the project boundaries move. We want to be flexible, right? You don’t have to document every change order because this is “just hours” and this is agile so the customer understands more requests just mean more hours. And you won’t need to notify the client that some of their original features aren’t going to be worked on to make room for their new requirements.
Sign up for Computerworld eNewsletters.