Mowing the grass, Revisited

John McCaffrey, Wednesday, June 24, 2009 @ 12:17 am

photo credit: great_sea

A few weeks ago Alice Toth and I had a conversation about how we can better serve our clients, and while we normally delve into project efficiencies like communication, developer training, and good QA practices, this time we both concluded that we need to do a better job of helping our clients reach their goals in the most efficient way possible, and sometimes that means talking them 'down' from the specific implementation idea they have, and finding a faster way to get there.

I said that one of our challenges is that sometimes our clients feel they've hired us to just  'Mow the Grass', not discuss the landscape architecture, so we're not always in a place to be heard when it comes to discussing the fundamentals of a project.  Alice wrote a nice post about what 'Just Mow the Grass' meant to her, and the strategy she's devised to find a nice middle ground.

Here's how I see it

I was thinking about the times when we encounter projects that are looking for what I call 'commodity software development' which is to say they feel they already have all the requirements, and everything is all figured out, and they just need a fixed-bid project to have it built. The reality though is that most of the time the idea is not fully fleshed out, and needs a good deal of work. While there might be some giant spreadsheet of features, usually the core business goals aren't clear, and many fundamental issues have not been covered.

If the customer thinks they have hired us to just 'mow the grass', they aren't in a place to hear any ideas about the big picture, they simply want us to 'build it', and as a consulting company we do need projects, and we want to have happy customers, so it seems we can either just build exactly what they asked for, and hope it turns out for the best, or we can help them confirm the business fundamentals a bit, and verify that the plan will work.

"I didn't hire you to question me"

Its not easy to get into the fundamentals with our customers, but the overall success of our work is dependent on knowing the fundamental assumptions that led to its creation, and in my mind that means we need to explore those ideas and test them out.

The other comparison/metaphor I had been kicking around in my head goes like this:

Imagine you are a building contractor. You build buildings to meet the needs of your clients, while adhering to the 'best practices' of your industry. If a client comes to you and wants you to build a new 'asian-fusion' restaurant in an area that you are pretty sure its not going to take off, you could suggest that another location might work better, but in reality, the customer probably isn't interested in what a contractor has to say about the viability of a concept restaurant. If the concept doesn't take off, the contractor still got paid, the builing is still standing and can be used for other purposes, and an outsider would not conclude that the restaurant failed because of anything related to the structure of the building itself. And while it might seem that the contractor doesn't care if the concept restaurant succeeds or not, let's suppose that if it had been successful it would lead to a long and successful relationship where the contractor and the business owner continue to work together on new buildings and projects.

So in this example, the 'building' project has specific and measurable requirements that are independent of the big picture success of the restaurant.

Now comparing that to a software development project that is core to the business. The software product that is created is inextricably linked to the success of big picture, and the software is unlikely to stand on its own and be usable for some other business. In fact if the big picture is not successful often times the software product itself is blamed.

Some of the fundamentals of a project

1. Is this a problem that users care about?
2. Is this the best way to solve that problem?
3. Is the business value greater than the cost to build it? (if not, how could we either lower the cost, or increase the value?)

I've noticed this fundamental failure to align the proposed features of a product to their expected return more on iPhone projects, and other smaller budget projects. That's not to say that its not present on larger projects, just that its more noticeable on smaller projects.

Ok, so now what?

Where as I was suggesting that we need to just dive into the fundamentals of the project and balance out the features relative to their expected value, and that its our job to 'Fight' to make sure we're building the right solution to the right problem, Alice's suggestion was that we need to consistently deliver high-quality results on the tasks we've been charged to do, even if it is just 'Mowing the grass', in order to establish trust and credibility, and earn our place at the 'big table' of advice giving.

What I don't like about Alice's idea is that its simple, elegant, logical, and its not mine!  (There's nothing worse than someone taking something you said and interpreting it to be more positive and cohesive than you realized)

You may have won this round Alice, but what will you do with customers like these?

Related posts:

1. Just mow the grass
2. Openfount Library Revisited
3. Business Reason #1 Revisited – ASP’s with Existing Apps
4. Thinking about starting a SaaS or eCommerce business?
5. Agile 2009: A reminder of why each team needs leadership

Comments (0)

Software Development

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment