Building an innovation lab - yes! Our first big fail!

I have the good fortune to be tasked with setting up an Innovation Lab within my company. Following a couple of rounds of brainstorming and chats within people within the business, I decided it was time to start doing something concrete. To this end, I launched an internal platform for gathering ideas (IdeaScale). My aim here was 1) to DO something 2) to replace the idea inbox which noone had used for over a year and 3) to get the organisation excited about doing creative work. In parallel, we launched a public side aimed at co-creation also using IdeaScale.

The launch got some good reactions and raised a few questions. Pretty much what I had hoped it would do.

A couple of days later, I was giving a presentation about ideas, innovation and culture when I got some very specific feedback that there was not enough buy-in and support from senior management and specifically the CEO. This was from my boss, who is also in the senior management team and had encouraged me to do things differently. Needless to say I was dissapointed. It was a blow and it knocked the wind out of my sails.

Afterwards as I was dwelling on this failure, I realised that it could not have been better. A main part of my presentation and something I see as key to innovation is an organisations ability to fail quickly and to keep on failing until it works. I was my own best example.

I had failed. Big time. Crashed and burned. Now was the time to learn from this and to do thinks differently, and hopefully better, going forward.

The one snag is, failing is not a experience. It took me a day or two to dust myself off. Watching a clothing ad helped.

Time to head off and fail again.

Back in the saddle

I knew it had been a long time between post, but so long seems ridiculous. I guess work and life get in the way of a good blog now and then. Since my last post, I have been gifted with two beautiful children.

I decided to get back in the saddle after attending the Business Analysis Conference Europe 2011 in London. Partly due to some of the inspiring presentations and good discussions in between. Partly as I realised that I wanted to share what I get up to. So this blog, even if no one reads it, is my way of keeping track of what I am doing as it happens.

More to follow.

My idea of key factors in delivery project success.

A strong, iterative focus that focuses on attacking requirements early and continually, and on producing software that (end) users want while meeting the needs of the business.

Sounds good, right?

The trouble is what looks great once you have worked it out on paper, does not always exceed when tried with actual, living, breathing people. So, how do you make sure that it actually delivers when put it to practice?

I think there are some factors that (regardless of process or methodology) need to be in place in order to develop good software. And by good, I mean software that adds value. The factors:

Communication
Multi-disciplinary teams
Collective Responsibility

Sounds straight forward. Common sense, almost. However it is easier said than done.

Indulge me for a little while, and pretend that I am in charge of putting together a project team to develop a new online application. I would pull a team together and appoint a lead for every discipline, typically this would be: Project Manager, Requirements Analyst, Information Architect, Architect, Test Manager. Each discipline lead is responsible for the quality and timely delivery of any artefacts, code, input from that discipline. They are also responsible for managing the people within their discipline in conjunction with the project manager. The idea is that this team of experts communicate well enough and often enough that all risks are out in the open and can be tackled using the collective skills and experience of everyone involved.

As Inception starts, I would do a small internal kick-off with the discipline leads to discuss risks, planning, resources, plan of attack, etc.. and then a larger internal kick-off (perhaps in the elaboration phase) with the whole team and explain the basics: what the project is about, why it is important to the customer, and why it is important to the company, the risks, the timelines etc… Effectively saying that we all own the project, and it is up to everyone in the room to make it happen together – no heroic all-nighters. I fell that something has gone wrong somewhere if project teams need to work late in to the night or weekends. If at all possible, I would arrange the second internal kick-off to start around 4pm, so by 5pm we would be done and could go down the pub as a team and enjoy a few drinks. Quite often people will raise issues, concerns, desires (e.g. new things they want to try or be responsible for) informally in the pub that they would not do in the kick-off. Reality is, some people don’t like to talk in front of big groups.

At some point between the two internal kick-offs, I would do an external kick-off with the key stakeholders from the business and the core project team (discipline leads). People need to know who they are working with. A face to go with the name. This is quite a simple session where we walk through the project aims, phase plan, and give an idea of who is responsible for what, and set expectations for the project in terms of communication, deliverables, what we expect from each other. Again the aim is to communicate and set the stage for a collaborative working environment. Quite often the message I try to get across is that we are experts in delivery high quality software, however we do not have the business knowledge that is needed to make the application have real value – this we need to get from you (the client). I have found that this also helps dispel any ill-feeling or questions like: who the hell do you think you are to tell me how my job works?

Communication between members of a multi-disciplinary team with the client that together are responsible for the delivery of an application that adds real value.


[I would normally bang on a bit more about usability and UCD, however that is for the Information Architect to do within the project.]

“Strive not to be a success, but rather to add value” – Einstein.

Tailoring RUP for web applications – part 1 (in case I think of more stuff later)

Traditional RUP practices greatly undervalue – if not completely ignore – the concept of User Centered Design (UCD). For me, UCD is a critical factor in developing any application, doubly so in web applications. According to “The Rational Unified Process Made Easy” by Per Kroll and Philippe Kruchten it is only in Transition – the last of the 4 RUP phases – that you should “Beta test to validate user expectations are met”. Leaving aside the question of where the user expectations came from in the first place, the Transition stage is too late to significantly rework a developed application. It may come down to a choice of leaving out the changes or postponing go live and having to do some serious rework. So much for addressing the risks earlier. As with other aspects of RUP, UCD should work iteratively and be present in each phase of the software development project. In fact, it should be a discipline within RUP in its own right.

Performing some basic UCD activities do not need to cost a lot of money or involve a lot of people. For example, you could do paper prototyping. Hang up some Wireframes (screen schematics) in a specific flow and ask potential users if they understand what is happening on each screen, ask them what they would do to complete a particular task. Another good way is to find someone not involved with the project and ask them to look at the first developed application, again ask them to perform one of the key tasks of the application. If they cannot work out how, then there is a problem. Arguably, this is already too late to begin thinking about the usability of the application.

In an ideal world, an Information Architect and/or Interaction Design involved from day 1 on the project (think roles not people) and as well as use cases being prioritised in terms of their Architectural Significance, they would also be prioritised according to the User Experience Significance. These two elements would be used in tandem to decide which use cases to tackle first (Inception) and also to drive any phase planning done on the basis of use cases. I think it fair to mention here that I assume that the Business Significance of the use cases is an automatic consideration.

Another Transition activity recommended by RUP is preparation of training material. One snag with this one, with a web application you do not get the chance to train the user group. Anyone get use the site (within security restrictions etc..) – it is on the web. A website that is OK technically can be more successfully than the best coded site in the world if it has significantly better usability. Think of the websites you have been to and have given up what you were doing. Now, why did you give up? How did you use the site? Did you read every options? Did you spend 5 minutes looking at pages other than the welcome page?

Kevin Costner once made a film called “Field of Dreams”, when thinking about usability I am reminded of a quote from that film:

If you build it, they will come.

That may work for a baseball diamond in a corn field, it does not work for the web. A better quote would be:

If you build it and they can find their way to it, they will come.

Someone finding their way is down to how usable, and sometimes how Accessible a web site or application is.

Time for a mass generalisation, a typical user will Google what they are looking for select the first link, scan the page, they will then select the first thing they see that they think may be what they are looking for (even if what they are actually looking for is 2 cms further down the page). They will scan the new page, if it is not what they are looking for they will head back to Google and select the next link. If you are lucky, they may scan the first page one more time. Is this how you picture users/customers using your website? Do you build it with them in mind? If not, then you have a problem/opportunity depending on which management guru is flavour of the month. A problem in that a lot of people who come to your site may only see the first page, even if the website is doing its job. An opportunity in that by improving the website, you could increase new customers, user retention, sales revenue, charitable donations….

How do I know?

In the past I have worked on designing government web applications that allow UK citizens to complete their income tax return. User base from 16 to 65, various skills and educational levels, various comfort and skill levels with internet use, etc…etc… and yet the application was instinctively usable and now has a user base of 2 million people who come back each year.

Best tool I know for communicating UI design: SWIPR - truly excellent, easy to use tool. You do need to have Visio 2003 though.

The Nirvana Method - aka my first mental scribblings

The following is something I wrote - the first thing actually - to vent my frustrations of tenory versus practice.

I’ve decided to come up with a methodology for developing software. Now before I get in to it I should warn you that I am not a techie, and do not (and have never) written code for a living. I have worked (in no particular order) as a systems analyst, business analyst, requirements analyst, information architect, and interaction designer. The Nirvana Method is my take on an ideal methodology. For me, this would combine the theoretical elements of RUP and the practical guidance offered by AGILE methods.

RUP out of the box is a giant beast of a thing, to even begin to use it you need to throw a good chunk away as your organization does not use/want/need* all of the roles/artifacts/activities* that comes as standard (* delete as needed). RUP then needs to be tweaked, which leads me to the conclusion that it is mostly a theoretical approach to software development.

AGILE methodologies are in essence a backlash against waterfall methodology and crushing documentation and processes that leave countless projects stuck in the mud. When looking at the AGILE Alliance site, especially the article “An Introduction to Agile Methods” that uses XP as an example, that the AGILE approach is aimed at getting the job done. AGILE deals with the more practical approach to developing software, for example pair programming and promoting single location teams (XP).

What are the common points of RUP and an AGILE method?
Iterative Development;
Deliver working software at the end of each iteration;
Highest Risks First (technical, business, usability);

OK then, what is specific to an AGILE methodology?
Define functionality as stories;
Programming in pairs;
Test Driven Development;

What is specific to RUP?
Model the business domain;
Define functionality as use cases;
Use Case Driven Development;
Work with components;

And what is just Common Sense (never to be underestimated)?
Communication as a key success factor;
Individuals as a key success factor;
Customer and end user involvement;
Requirements will change;
Planning will change;
Learn as you go, write better code (refactor);
It costs less to fix a requirement than an application.

So my big question is why cannot all of the above elements be combined? It can, the Nirvana Method. The Nirvana Method:

An iterative development methodology that delivers working software at the end of each iteration, attacking the highest risks functionality first based on a sound understand of a specific business goal(s) and environment.

The Nirvana Method believes that communication, individuals, customer involvement, and user centered design are critical success factors that are needed to combat the reality of changing requirements, priorities and planning.


OK, so it is not really a method; more like a statement of how I would like projects I am involved with to work.

First past the post

Welcome!

So here it is, the first post. Exciting stuff. For me at least.

So, why did I create this blog?

Well, I have recently changed jobs and have been spending a lot of time looking at improving software development processes for my new employer and their customers. The main idea is to take RUP and customise it based on experience (mine and others). Along the way I have been diving in to the theory to check my practice, and this resulted in a lot of frustration, so I decided to start a blog to vent. If you find a couple of useful ideas amongst my venting, excellent.

“In theory, there is no difference between theory and practice, but in practice, there is.” Yogi Berra