Archive for the ‘Agile’ Category

RFP response documents are not well liked whichever side of the fence you sit on, they are painful to write and even worse to read.  Their greatest failing though has to be in their ineffectiveness at helping people decide which solutions to buy.  In the end it is people who buy solutions not companies.

Like pulling teeth

What is it that makes RFP responses so universally despised ?  Well where to begin.  Firstly they are painfully unwieldy – full of many hundreds of mind numbing and often irrelevant questions that are generically reused across many different RFP’s.  Secondly there is a general suspicion that every vendor will say they do everything and fully comply to all of the requirements.  It becoming more of an exercise in whose RFP response weighs the most rather than who has the best solution.  All of which results in a sense of frustration at the utter futility of the whole exercise – people just going through  the motions as no one is brave enough to stop the madness and excessive waste of time and resources.

A better way

Why do people continue to follow this broken, time consuming, resource hungry process ?  It’s hard to say – probably the  involvement of so many people and the mountain of documentation provides some kind of reassurance  that due care and consideration has been given prior to spending company money for a significant purchase.  But in nearly all cases this is a false sense of security.  Most of the real value coming from the interactive discussions with the vendors rather than the forest killing tomes of response documents.  In these enlightened times a new more agile approach to selecting software is demanded.

It’s easy to see that there is much wrong with the RFP process and in particular the associated documentation.  The question is what would be a better approach.  To that end I would like to propose the following software selection manifesto.  A call to arms to everyone who has ever had to endure writing RFP responses or given up the will to live reading them.

Software selection manifesto

Favours the following

  • Interactive dialogue over documentation
  • People over company background
  • Realistic prototypes over slideware and demo’s
  • Reference  data over marketecture

Interactive dialogue over documentation

People much prefer talking to people than reading huge documents.  If there is to be some documentation it should be minimal and really serve the purpose for laying out a framework for the face to face discussion to take place.  Interactive discussions allow key areas to be explored in a way that no document can address.

People over company background

People buy from people not companies.  The cultural compatibility and the confidence in the people who will both manage and help deliver your solution is worth more than all the company marketing blurb you could care to consume.  Which is not to say due diligence shouldn’t be done on company financial and commercial viability – this is of course necessary.  However with all things being equal the people make the difference between success and failure of most software projects.

Realistic prototypes over slideware and demo’s

Prototypes or proof of concepts allow a particular use case with relevant data to be explored.  With some well chosen use cases it is possible to get a reasonable understanding of how a solution may help meet the requirements.  This is often far more valuable in understanding a solution’s fit to the requirements than trying to mentally map slideware and canned demo’s to your specific needs.  The reason for the ‘realistic’ qualifier is that often people lay out too many complex use cases that simply can’t be effectively delivered in a reasonable timescale.  Here it is a case of quality over quantity for prototypes.

Reference  data over marketecture

Is it more useful that I draw you a diagram showing how the architecture will scale or that I  share data with you about a customer who is running the solution with similar traffic volumes and users with equivalent data sets on a given hardware footprint ?  No amount of architecture discussion or drawing will replace the reality of real data proof points.  Architecture diagrams have their place but real data should  be the most persuasive evidence in making a decision.

In the end these are guiding principles not a recipe or process to be followed.  Their objective is to provide a framework that is  more pragmatic and efficient in the use of both time and resources in assessing whether a solution is really fitting your business needs and if the people from the vendor will make it successful.


Read Full Post »

Agile software development and project management has become much more mainstream in recent years.  This is reflected in the increasing  number of blogs and books available on the subject.  But for someone approaching the subject fresh it can seem somewhat overwhelming and unclear where to start.  It can also look like you have to go read 20 books just to understand it.  Which is unfortunate as underpinning the whole approach are some very clear and simple edicts from the Agile Manifesto :-

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Agile then in it’s purest simplest form is about removing layers of complexity and unnecessary paperwork and processes in software development.  It is really about working closely with the customers and end users and iteratively evolving the software to meet their needs.  Understanding these principles is important and can serve as a guide to understanding how to navigate through the many agile techniques and tools.

Agile projects still contain the same kind of ingredients as any software development project namely

  • gathering and documenting requirements
  • planning and estimating
  • development cycles
  • testing
  • managing change

Where Agile often differs from other software development approaches is in the quantity and order of these ingredients in the recipe, by doing just enough requirements gathering and iterating quickly through build/feedback loops.  Estimating is still important to see what areas can be addressed during those iterations but often actual team velocity as measured through initial iterations is a better guide to future progress.  You don’t plan too far ahead so the next iteration can be determined based on emerging requirements or understanding.

The tools of an Agile team

Often associated to Agile projects but really just pragmatic best practise techniques versus anything inherent in an Agile approach

  • User centric stories to describe requirements leading to Agile goal of less documentation
  • Wireframing visual design – much quicker and easier to change than developing UI using software
  • Relative estimation and team based estimating
  • Time boxed iterations
  • Test driven development
  • Retrospective review cycles
  • Automated and continuous build/integration

However which of these you choose to adopt very much depends on the needs of the project and the situation at hand.  Keeping it simple is key as well as adapting based on the experience of both the team and client.  Trying to get a team to adopt new approaches completely alien to them will often result in failure.  In the end Agile should be about people interacting which should be very natural and processes and procedures should be minimal and not interfere with progress.

In the end you need to adopt the approaches, techniques and tools that are appropriate to the project, team and client and this will often vary.  Agile techniques can be very effective but the key is embracing the underlying principles as outlined in the manifesto and not getting lost in acronyms and debates about methodologies.

Useful resources on Agile approaches


Read Full Post »