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.
No comments:
Post a Comment