Critical success factors for super short projects
Equal Experts was recently commissioned to develop an iPad application to coincide with the launch of the iPad in the UK, for Rightmove.co.uk, the UK’s number 1 real estate portal. Being a non techie tech junkie with the right domain experience, I was asked to lead this initiative. And I just couldn’t refuse an opportunity to be on the bleeding edge of cool. Despite the fact that launch was less than five weeks away, and despite the fact that I had no development team!
Thanks to Equal Experts’ extensive network, we managed to team up with Robots And Pencils Inc, a Canadian outfit with iPad and iPhone development experience, and in a matter of days the project team was formed, contracts negotiated (verbally) and the project started.
Now, four weeks is an extremely short time to deliver what amounted to a functionally substantial application, in a domain that was completely unfamiliar to the developers. With the delivery date critical for the realisation of the business objectives, delivery of a stable and engaging application relied on a couple of highly critical success factors (and a dollop of calculated risk). Although these factors will differ from project to project, there might be some universal value in explaining these. In a later article, I will explain a little more about the process we applied in this project.
Critical Success Factors
- Clear and well prioritised business objectives
- Functional and UX simplicity
- An experienced, committed development team
- Trust, and as little interruption as possible
- “Extreme” agile
Is on-time delivery critical? Is scope critical? You can have one or the other, but not both. In this particular case the client was quite clear: maximise brand exposure by going live on the date of the iPad launch, when consumers and the press are really hungry for iPad content. But, make sure that the publicity is positive, by delivering an iPad experience that is familiar, functional, stable, yet unique to the iPad. Scope took a distinct backseat (to a point – there will always be a minimum acceptable set of features, otherwise there won’t be a project).
User interface design, user experience and workflow needed to be pretty much spot-on from the outset – we planned for refinements in the UX, but not for a complete change in approach. Simplicity and a limited scope is key to getting the UX right the first time.
Simplicity requires less testing, and it creates less opportunity for things to go wrong. Complex workflow and complex UX tend to generate unpredictable, and usually large numbers of small defects, cluttering the project backlog and distracting the developers from getting on with the big stuff.
The iPad is a device with incredibly rich UI capabilities, but with relatively little processing power. Stability and responsiveness are key to a decent user experience. Performance and stability must be architected in from the outset – as with the functionality and the UX, there would be preciously little time to rethink the architecture midway through the project. The only way to mitigate the risk of architectural failure is to make use of highly skilled and experienced developers.
Also, don’t try this type of project without significant domain expertise and knowledge of the client’s existing products on the team.
For me personally, a huge learning curve. When you require the unthinkable from a development team, you HAVE to trust them. You have to allow them to work in the way that they think is best. You have to give them some space.
This by no means imply that you let them be and pray for the best, it merely implies that you have to bend the process in a way that enables them to be productive. You cannot impose a process on the team, you have to fit a process around the team. More about this in a later article.
It is also very important that the client trusts the team enough to let them get on with it. Make this quite clear from the outset (on our project, this was not a problem at all – prior to joining Equal Experts, I have worked for Rightmove for a very long time – mutual trust was implicit).
Very short feedback cycles, very short iterations and tight control over the project backlog. For this project, the first two weeks were relatively unstructured, basically creating the architectural foundation and creating the most basic required functionality. Thereafter, we delivered production ready code once a week, with daily or two daily reprioritisation of the backlog. I will explain the approach in more detail in a subsequent article.
As it turned out the project was remarkably successful, with the app shooting to the number 2 position in the UK free app download charts (and number 1 in the lifestyle section). And favourable reviews from users, bloggers and twitterers.
