Building relationships with customers based on trust is difficult. When you are providing your customer services, rather than tangible deliverables upfront, this becomes even harder. Trust is essential in software projects of any style, since it absolutely will affect the perception and success of any deliverable. I don't proclaim to be an expert in the software services business, though I have run several large software implementation projects, while being involved in numerous others from the sidelines.
Right now, I'm running a business process management (BPM) and document management implementation for a global insurance company in Mexico City, while being involved in a technical consultant sideline role for the same company in Chile. If I had been the customer I might have chosen to stagger the implementations to make best use of the reusable components and experience, but the reality of budgets and timelines does not always allow. Either way, we have two projects running simultaneous, for the same parent company in different countries, following very different implementation styles:
- Chile - traditional (waterfall) model: analysis, design, development, testing, rollout
- Mexico - a modified scrum: iterative analysis and development with iterative timeboxed deliverables, final testing, rollout
The challenge from either approach is proving to be building the trust of customer early enough in the project to set out on the right track for the style of project you want to run. So here is what I'm seeing.
Large insurance companies continue to be conservative in nature, meaning that a traditional software development cycle is something they are familiar with and comfortable with. The problem is that the trap becomes paralysis through analysis. The development of the solution may never get started, because it is impossible to get the customer to agree on the scoping and initial analysis. In this case, I can't tell whether the design will deliver what the customer really needs, as they have no experience with the best practices or limitations of the tools they are building on. Within a reasonably well defined timescale they are going to get a set of applications that work according to the design. Trust in this environment has come from extremely tight scoping and analysis sign-off, and will hopefully build into a more flexible trust soon.
Taking another approach, I've been working on my customer to move them to a more iterative project. This has been uncomfortable for them, as they feel that they want to know what they will get before agreeing to the scope of the project. There are items they are clinging onto strongly that I would bet a fresh fish taco on that will be dropped (or at least significantly diluted) by the end of the development as they understand what these requirements mean in reality. The challenge here has been building enough trust between client and consultants early in the project that they will get a usable deliverable in their timeline. Perfection has never been promised, and there continues the risk that the scope which forms the contract is open to interpretation. The deal here rests on a combination of personal trust and constant expectation setting, aligned with a flexibility within a restrictive scope.
Which project will work best is yet to be seen. Chile has the best chance of meeting the customers initial requirements most closely, but has the equal risk that these requirements will not provide the full value that could be envisioned, requiring a further deep iteration. Mexico has the best chance of being delivered to time and budget, though with many gaps that the customer will return to in a second phase. Similar result, we'll see which gets closest in expectations met, time and budget.
My belief right now is that the iterative approach is a good fit for the tool we are using, and a loose BPM methodology. I'll be letting you know whether this was a good bet or not!
A post from the Improving It blog
No comments:
Post a Comment