StartNow - A fresh approach

[dale_brown]

So why are we taking a different approach to deploying projects? What are the benefits to using StartNow in your ServiceNow deployment or even using it to help deploy any piece of software within your organization?

There are great reports out there done by well-established organizations (Standish Group, Harvard Business Review to name but a few) that have discovered some startling facts on how projects fail! One that really interested me came from the Standish Group, interesting enough, called the 'Chaos Report'! From this report, some of the key findings read:

-30%+ projects are cancelled before they reach completion
-Over half of these projects are nearly 200% over-budget!
-Only 16% of projects are completed on time and on budget
-For Larger companies, this completion figure falls to 9%

I guess 16% (or 9% if you're a large company) is better than 0% success but it's not that great!! Then there's the issue that even though these projects came in on budget and on time, they were a shadow of their former self with respect to the original specification!

Think about a traditional waterfall project (take any project from your past experience), think about the excitement at the start, then the requirements gathering exercises, then the months of building then the testing and finally the roll-out…ask yourself this; how many of those original 'cool' features built into the product were really used? Take the analogy of the iPhone…how many of you on day 1 of unwrapping it from the box, went onto AppStore and download all the possible apps you could fit onto that phone…ask yourself this; how many are you using right now??? This is the same as enterprise software!! We do a really good job of getting people fired up and promising lots of cool stuff. The requirement gathering exercises are a bit like a Christmas shopping list for a 4 year old…I want…I want…I want…I must have…

Again, another published figure reveal the actual use of software features looks something like:

-45% Never used
-19% Rarely used
-16% Sometimes
-13% often
-7% Always

So you can see that all that excitement in the design stages really does not pay out in the end!! Lets pause for a moment, It's not that these ideas are bad by any means but it could be down to the fact that during the life of the project the requirement has changed or that it's become a 'nice-to-have' rather than a 'must-have'.

Here's where we struggle in a traditional waterfall project, we struggle to accommodate change, and nobody likes change, especially half way through the project. Process owners and key stakeholders know this fact so they push really hard in the design stage to get as much feature / function in before it's too late! Everything is a must have, regardless whether they need it or not…. I want…I want…I must have!!

Ok, so what are we doing about this problem in StartNow ? As I mentioned in an earlier blog, I talk about using a mixture of Project and Scrum to deploy ServiceNow. Project sets out the stall…get's the right people from both the customer and from ServiceNow in at the right time in the right place. We know from the plan the 'estimated' timescales and when this project is 'likely' to finish. This we know from the original scoping work. What we DON'T know is the nuts and bolts deliverables…we know we need to deploy Incident Management or Service Catalog with X number of integrations what we don't know is how. This is where the Scrum piece of the jigsaw comes into play! We utilize the strengths of Scrum to get into the detail and run iterative work packages; at the same time making sure we're still on track to meet the (end) customers requirements.

We do this several ways in StartNow :

1.Clear and Transparent project detailing of the end to end project including individual Releases and Sprints (Sprints are time-boxed)
2.Each of the requirements are documented as Stories, placed into a weekly sprint, built and then reviewed by the customer
3.Make changes quickly should any issues arise. If we're going to fail, fail fast!!

To be honest, we're doing the same type of work as we would in a traditional waterfall project…we go through the same type of Gap Analysis workshops, it's when we come to the deploy stage of the methodology is where it differs, instead of building all at once and 'lob it over the fence' for testing, we build in small iterations (Sprints) until we have a potentially shippable product that the customer is happy with. This is then ready for testing, training and the transition to the operational state where the testing piece is really seen as a tick in the box.

In the next session, I'll go into more detail about how we go about this…