Stop Persevering, Start Thinking

Consulting and software projects do funny things to incredibly smart people - they make them dumb and irrational. I've experienced it first hand (though I don't admit in public that I rate as incredibly smart).

So what's the deal? We've all used some variation of the phrase 'you can't see the wood for the trees'. That's what tough projects can do to people. They get so involved in the details of the project that they either don't notice that the project is starting to fall apart, or don't notice that it was never really together enough in the first place to fall apart. Then disaster strikes - the shit hits the fan - the customer starts ranting (more than before) and the incredibly smart people fall into the worst trap possible; they keep doing what they were doing before, just now at nights and weekends.

There are only three people or roles of people that I think can help prevent, or at least fix this when it happens:

1) The project manager or leader - the person who is falling into the trap and taking the project with them

2) The project manager's boss, mentor, or someone close to the project - preferably someone the leader trusts

3) The client - the guy who is being the biggest pain in the ass that there is right now

As a project manager, how do you prevent this? Well, I don't know that you can, but try following your own rules maybe and put in some checks or balances for your own personal behaviour, independent of the project.

• How many hours have you worked this week? Is it significantly greater than the average project you run?
• Have you started to find excuses why you can't do things differently in the project (the client will say no to everything you suggest, its just impossible, etc)?
• Have you made your team members miss personal events, weekends, etc?

As a project manager, when you really feel you can't take an hour off, do just that. In fact take two. One hour, complain and moan to yourself, go for a walk, do something that forces you to get away from the PC. The second hour, start brainstorming about how you can change the project; what is the stuff that is unnecessary, what can you do differently. This is brainstorming. Nothing is impossible. You can work out in the third hour (three hours, impossible!) what is going to be most effective at getting back on track with minimal impact to the value of the project.

As the person the leader trusts, have you seen this issue getting bigger? How can you help? I'm no counsellor in this stuff, and have always enrolled in courses of 'tough love'. Painful for everyone involved, unfortunately, though often gets the job done. Help the leader brainstorm, and visualize where the value in the project comes from, which is often not the individual details. Help them understand how they might sell some of the changes to the client.

Then there's the client. Why in the world would you want to put your project at risk, along with the potential risk to your business and credibility? So maybe its time to start compromising a little. Screwing the vendor or consultant out of every last bullet point rushed into the last draft of the contract or scope may just lead to a valuable, expert team becoming so overwhelmed that your aim of getting the perfect system may result in you getting nothing. Or worse still, a vendor that provides a system that looks great until its put into practice (cos those little features and design points you bullied them into were actually meaningless or of minimal value). Finally you could end up with a system that is functional, but nobody wants to go near it, in-house or external, because its tainted with bad-project vibe.

So, when you find that you just need to persevere a little more (beyond the 70 hours a week you already are), or need to shout at the vendor beyond the point that its fair sport, its possibly time to stop, put down your tools, and do the hardest thing of all. Start thinking about what you can change, and what you can ask the client or vendor to be changed, to get the project back on track.

A post from the Improving It blog

Download the podcast of this blog post

Custom software development is really better than complex configuration?

Another week in Mexico City, and nothing chaotic or remotely strange (by Mexico standards) happened. Life is heading back to its usual modus operandi. Offices have thermal imaging cameras at their entrances to catch suspected flu carriers, but traffic on the streets is back to its chaotic self and everyone is happy that this signifies a return to normality.

As for my current project with the large multinational insurance company, things are getting interesting. The team has entered an iterative 'construction and validation' series of development 'sprints'. The Case360 product is doing exactly what it should: providing a flexible platform for rapid development of process and document management solutions. Its nice to know that the messaging I put around it from a product management and marketing perspective while in the company was really true! I have to hope that Global 360 manage to keep some level of focus on the product in the future, since it really is a great technology.

Some interesting facets of using a product of this type, which allows production solutions to be configured without coding (beyond a little script here and there), are:

(a) how fast you can put skeleton solutions together that you refine over a series of iterations

(b) what a waste of time documenting and formally designing a solution can be

(c) customers start to think this is so easy they can do it themselves

The power of a software product that allows configuration of meaningful solutions, based on its templates and best-practices, also carries some risks. The major one is (c). A deep understanding of what the product offers, and how all the available pieces fit together in a usable and maintainable way is required by the consultants doing the work. Otherwise the solution becomes a series of disconnected and confusing components for the end user to navigate (how many of you remember Lotus Notes applications?). And some complex requirements, though possible to meet, require some serious thought, prototyping, rework, and occasionally coding, that can be hard for a customer to comprehend.

Its strange to me that customers are often willing to accept the opaque nature of custom software development if the whole solution is based on this. But if a solution is largely configuration and clever reuse of templates, anything complex is looked at with contempt, even though that the final solution is far more manageable than most custom software. There's no pleasing some people!

A post from the Improving It blog

Trust is key in software projects

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