How to become an Agile vendor…Where are we going?

08 January

In the last part of this blog series, we looked at some of the challenges and potential pitfalls software vendors face when moving to an Agile delivery environment – this next part is now concerned with taking this forward into establishing a product / project vision and project charter to guide your project delivery.

 

Product / Project Vision

So you’ve been selected for a contract, made it through contract negotiations (while hopefully still being in possession of your soul) and are ready to reap the rewards by blowing your customer away with speedy, flexible and high-quality delivery, right? What sounds so easy and straightforward on a piece of paper can be surprisingly tricky in the “real world” though, so here are a few pitfalls I’ve come across while working at vendor organisations and a few thoughts on how to overcome them:

Understanding the project vision is critical – like with any other (Agile) project, you gotta know where you’re going before you set off. While t his sounds like a lot of common sense, many clients (and vendors, for that matter!) believe that the product vision is irrelevant for the delivery of software and are therefore hesitant (if not downright unwilling) to share the vision for the product they’re commissioning. In my opinion, this is the difference between “writing software” and “delivering a solution” – the former adds lines of code, the latter adds business value – you decide!

 

Project Charter

There are a variety of tools and methods you can use to gather and record information relevant to chartering a project which would go beyond the scope of this blog – whichever way you go about identifying the project / product vision, in my experience, it can be useful to focus on the following points:

  • Drivers for change & strategic fit

Here we would look at what is making us do this project in the first place and how does it fit in with the overall organisational strategy. In my experience, this can be a hard one to extract from clients since many organisations don’t openly discuss organisational strategy with all of their employees, let alone with 3rd parties. My recommendation: if your client is unwilling to share, you may well benefit from rethinking the relationship you’re about to enter – will you ever be able to provide a solution to an unclarified problem? Will you ever be able to advise a client on how to make the most of an opportunity that you don’t fully understand yourself? Understanding the reasons for change and how they will (or won’t!) fit into the organisational strategy is your base for moving from “code monkey” to a true and trusted advisor!

  • Business Benefits, goals and objectives

Here, we would be looking at identifying what it will mean to deliver the project successfully for your client. As with the above point, this can often be hard to extract since it may well include the disclosure of financial information. If this is an issue you might want to suggest / consider a Non-Disclosure Agreement (NDA) or similar.  If this feels like pulling teeth, remember: will you be able to satisfy a client who is unwilling (or unable!) to explain what would satisfy them? Is your client willing to carry the risk associated with a lack of clear, defined and agreed project success criteria?

  • User benefits, goals and objectives

Once you’ve established what the organisation wants from the project, do the same for the end-users of the system. Simple, really!

  • Business and User impact

What impact will this change have on the organisation and the end-users? What is the ongoing maintenance impact, are there any additional training / marketing / comms / etc. requirements that need to be taken into consideration? In my mind, there is no such thing as a “software solution” – software is always part of a wider, “business solution” and in order to be effective, you have to understand the environment you’re operating in.

  • RAIDS

What risks can you or your client see in the project at this stage? What assumptions is the above information based on? What issues currently exist? What dependencies do we need to take into consideration (hint: it pays here to think about how the product will be rolled out – a common dependency is training of those who will be supporting the system, which may well depend upon a predefined training cycle). Aim to understand and prioritise your constraints – value sliders can be a great way to communicate prioritisation in project constraints and avoid the “Iron Triangle” (for more thoughts on how to “breaking the iron triangle” check out http://www.ambysoft.com/essays/brokenTriangle.html )

And while talking about project constraints, don’t forget to talk about:

  • Quality (!!)

Talking about quality?! Now?! Eek!!! Surely the answer I’ll get from my client will be “defect-free” or “perfect”?!
This may be a tough conversation to have, but I think it’s only fair that you’re honest with your clients and tell them that there’s no such thing as “bug-free software”, there’s only “stuff we’ve not tested enough yet”! Testing costs money, fixing bugs costs money – how much is feasible to spend and how much your client is willing to spend are important factors in understanding your project constraints and environment and will help you become a trusted advisor for your client.

  • Project buy-in

What buy-in does the project have in your client’s organisation? This will help you gauge the risk of the project a) being cancelled prematurely, b) you not getting the time and resource from your client to work in a highly collaborative environment and / or c) the project changing direction significantly after you’ve started. My recommendation would be to gain an understanding how well (or not!) an Agile approach is understood and supported by your client, thus (hopefully) avoiding your delivery approach getting in the way of your delivery. This is also a good time to re-iterate the commitment required from your client to deliver the solution successfully – the role of the Business Representative / Product Owner is a crucial one in an Agile environment and the time necessary to do it justice is often underestimated!

  • Product Rollout strategy

Regardless of whether you’re building an in-house version of Minesweeper with two people in the back shed or a new product that will revolutionise how your customer base views the world, it pays to start thinking about how exactly you will roll your new product out.

 

A lot of the information above may have come out of an earlier bidding process and a fair bit would already have been established by the clients’ project team prior to engaging you (after all, they did find funding for the project…) – also, none of this is exactly specific to Agile, however the main differences I’ve experienced between product visions in Agile and waterfall environments are:

  • Collaboration vs provision

Aim to work through the above points collaboratively – while you may not be able to contribute as to why your clients are looking to carry out a particular project, your value is in sanity-checking existing assumptions and / or bringing different experiences and expertise to the table. Take the information that you have gathered during the pre-sales stages, do some research and bring additional information into the discussions. Most importantly, use this process to set realistic expectations around what is and isn’t possible / feasible and building a trust relationship rather than just working through the documentation provided by your client.

  • Understanding vs documenting

Aim to understand the problem / opportunity definition driving the project, the customer base using the proposed project output, the benefits your client is hoping to gain and how these have been established. Yes, you might want to write some of this down to come back to at a later stage, but remember that first and foremost you should aim to thoroughly understand what your client is hoping to achieve and how the services they are recruiting from you fit into the bigger picture.

  • Clarification vs omission 

Lastly, you may be surprised by how much of the information above has previously been “skipped” or deferred by your client as “too hard”. In the past, I have come across many organisations which have done little to no vision and goal setting for major projects and started significant development efforts having no understanding of success criteria. Don’t omit parts of the Product / Project Vision just because “they’re hard” – see the hard work as an investment to future success!

So here’s the skinny on establishing a Project Vision and Project Charter – next time we’ll be looking at how to Plan for Success, so don’t forget to check back in!

CHAT
EMAIL
CALL