When I was first working in IT, I was used to coding from a specification. I was so busy struggling with Cobol, JCL and DL/1 - yes, I'm that old! - that I didn't stop to think about where these specs came from.
A couple of years later I was working for VSEL amending some programs (as we called them in those days) and having been told what we needed to do, we'd look at the existing code and the database and work out what to do, often coding as we went.
It was only on my first contract that I began to see a better way of doing things. There were some people on the development team who didn't write code but whose job was to write these specification documents that I remembered from my first job. We all sat in one open plan office and each developer worked with one systems analyst.
I found this tremendously interesting, especially as I began to get a say in how the programmes might work, and over the course of my next couple of contracts I made the transition from developer to systems analyst.
At this point, you might well be saying to yourself "this is all very well but what's a systems analyst?"
Good question.
The business analyst collects the business requirements. So, for example, a new system might track books in and out of a library and each card holder is allowed to have three books at any one time for up to a fortnight. That's a nice simple piece of business analysis.
The systems analyst, though, has to design the system, the database and the logic. It's the systems analyst who will typically find the gaps in the business analyst's documentation, sending them scurrying to the client with questions like "but what happens when the card holder has had a book for a fortnight?"
It is this final specification that the developer will code from and, whilst the developer has some leeway in exactly what they build, it is that specification written by the systems analyst that determines what will be tested. The programme should do what the specification says and no more.
Of course, this additional step appears to be very time-consuming and it is but, as is so often the case when a company does things properly, it pays dividends. The approach that simply sets the developer coding with a bunch of requirements often means that the developer will get halfway through before realising that he needs to go back and change something he's already written. It means that the client isn't suddenly presented with quite fundamental questions during the build process, which may be a little unnerving. And, in a constructive way, it presents a contract between the analyst and developer, who have agreed what is being built. If the requirements change and the spec needs amending, the developer can very reasonably ask for more time.
Furthermore, the specification forms an excellent basis for system testing, as it details precisely what the system is supposed to do.
As a business, Meantime prides itself on delivering on time, on budget and to specification. The systems analyst's role is key in helping us to keep this promise to our clients.
Friday 16 November 2012
Friday 1 June 2012
The important art of business analysis
"Hello. Is that the garage?"
"Yes, it is. Good morning. How can I help you?"
"I'd like to buy a car, please?"
"Great. We'd certainly be pleased to help you with that!"
"Oh good. Can you tell me how much it will cost?"
"Er..."
Well, OBVIOUSLY, you wouldn't go into buying a car like that (although I have in the past wished that you could!).
Of course, what you would actually do is tell the garage your requirements. Some of those might be quite specific: you might want a diesel engine or a sunroof. You might also provide a bit of background information, such as the fact that you have three children. This will give the salesperson an opportunity to add some value, as he (or she) might ask, for example, whether you want rear doors with childproof locks on them. And, of course, no sale would be complete without an attempt to sell you a few bits and pieces that aren't strictly necessary, like alloy wheels.
I'm mentioning all this because this current instalment in why IT projects fail concerns the Business Analysis stage. Now this isn't strictly sales - that's where my analogy breaks down - but a good business analyst will collect information not only about your specific requirements but also your business.
This enables the analyst to do three things: firstly to contextualise your requirements. Secondly to bring their experience of similar companies and projects to bear and thereby add value. And, thirdly, to ensure that the development fits in with your requirements strategically. After all, there's no point in buying a five-seater if your family is expecting a fourth child!
So, a business analyst needs to be a good listener. They need to ask you about your business, where it's come from, what it's doing now and where it's heading. The analyst needs to understand what systems the company uses now and whether any new software will be required to integrate with them.
Next the business analyst needs to listen to your requirements, using their experience to understand whether what you're asking for matches your stated intentions. Here their experience of other projects and companies will be of value, possibly preventing you from making mistakes and helping you to benefit from the experiences of other people.
The business analyst should also be able to make suggestions about what other options you might want to consider doing that aren't currently part of your plans. The cross-pollination of ideas across sectors is not always obvious but a good analyst will be able to spot them.
Once you have had this meeting - or possibly meetings - the business analyst should provide you with a business requirements document, which should detail the scope of the project and the requirements that you want satisfied, whilst also recording any discussions around future development. The document might include some design work but, really, it should be a summary of your business requirements.
Once you've approved this document, the company for whom the business analyst works should be able to give you a reasonably accurate estimated cost for the work. However, I wouldn't expect them to quote for the project until the more detailed analysis is complete and it wouldn't be unreasonable for their company to expect you to pay for this detailed ("systems") analysis, which will take days or even weeks. Next time I'll write about systems analysis and that stage of the project.
I think it should be fairly clear from what I've written here just what the issues are that might arise if the business analysis is not done properly; a client who ends up with a system that is not right for their business.
"Yes, it is. Good morning. How can I help you?"
"I'd like to buy a car, please?"
"Great. We'd certainly be pleased to help you with that!"
"Oh good. Can you tell me how much it will cost?"
"Er..."
Well, OBVIOUSLY, you wouldn't go into buying a car like that (although I have in the past wished that you could!).
Of course, what you would actually do is tell the garage your requirements. Some of those might be quite specific: you might want a diesel engine or a sunroof. You might also provide a bit of background information, such as the fact that you have three children. This will give the salesperson an opportunity to add some value, as he (or she) might ask, for example, whether you want rear doors with childproof locks on them. And, of course, no sale would be complete without an attempt to sell you a few bits and pieces that aren't strictly necessary, like alloy wheels.
I'm mentioning all this because this current instalment in why IT projects fail concerns the Business Analysis stage. Now this isn't strictly sales - that's where my analogy breaks down - but a good business analyst will collect information not only about your specific requirements but also your business.
This enables the analyst to do three things: firstly to contextualise your requirements. Secondly to bring their experience of similar companies and projects to bear and thereby add value. And, thirdly, to ensure that the development fits in with your requirements strategically. After all, there's no point in buying a five-seater if your family is expecting a fourth child!
So, a business analyst needs to be a good listener. They need to ask you about your business, where it's come from, what it's doing now and where it's heading. The analyst needs to understand what systems the company uses now and whether any new software will be required to integrate with them.
Next the business analyst needs to listen to your requirements, using their experience to understand whether what you're asking for matches your stated intentions. Here their experience of other projects and companies will be of value, possibly preventing you from making mistakes and helping you to benefit from the experiences of other people.
The business analyst should also be able to make suggestions about what other options you might want to consider doing that aren't currently part of your plans. The cross-pollination of ideas across sectors is not always obvious but a good analyst will be able to spot them.
Once you have had this meeting - or possibly meetings - the business analyst should provide you with a business requirements document, which should detail the scope of the project and the requirements that you want satisfied, whilst also recording any discussions around future development. The document might include some design work but, really, it should be a summary of your business requirements.
Once you've approved this document, the company for whom the business analyst works should be able to give you a reasonably accurate estimated cost for the work. However, I wouldn't expect them to quote for the project until the more detailed analysis is complete and it wouldn't be unreasonable for their company to expect you to pay for this detailed ("systems") analysis, which will take days or even weeks. Next time I'll write about systems analysis and that stage of the project.
I think it should be fairly clear from what I've written here just what the issues are that might arise if the business analysis is not done properly; a client who ends up with a system that is not right for their business.
Friday 30 March 2012
Scoping your IT project.
Wow! It's been a while since I was last here. Happy New Year! The last six months have flown by as we've acquired new projects, clients and colleagues. Plus, as readers of our newsletter will know, we've spent the first three months of this year rationalising our servers onto a single cloud-based platform. This has been an enormous undertaking and I'm absolutely delighted by its success, which was managed with absolute minimum disruption to our clients.
But in my last post I was starting a series of posts about why large IT projects fail. I had originally written a list of all the items I want to cover and this had gone missing. After I started sketching out this post I found it again and I was pleased to see I'd been consistent in what I see as the first thing to consider, and that is scope.
When I'm talking about IT or trying to explain it to non-technical folk, I often find that talking about building is a good analogy. So, let's imagine that you're going to build an extension for a new kitchen.
First of all, you need to consider the rest of your house. You might not be doing any work there but there's plumbing and electricity to consider, and the stresses on the existing infrastructure. This, then, is not the time to discuss whether the bathroom needs renovating although if that's being done at the same time, you need to make sure you aren't moving a pipe that you're planning to feed into the kitchen.
Similarly, then, for your new project, before you start talking about what it needs to do, what constraints are there? If it has to exchange information with other systems, how will that work? Have you checked whether those other systems have their own changes planned?
Next, focus on the essentials. What needs to to be done in this initial project? It might be sensible to defer considerations such as floor tiles, painting and decorating, and kitchen furniture. Sure, the kitchen might not be usable until these are in place but putting those to one side, you can focus on a manageable amount of work that is quite different in its nature. Your joiner is unlikely to want to sit in on a conversation about Italian tiles.
So, for your IT project, look at what needs to be achieved. Yes, you might want a letter printing facility but that's academic if your client data isn't right. Of course, you want to know that that will be a requirement at some point - you want to bear these things in mind - but for now you need to focus on the core deliverable. This enables you to keep your team smaller, which facilitates communication and eases change management. It also means you are less vulnerable to changes in requirements - you have a smaller target - and when those do arise, impact analysis is simpler.
Once you have reached this point, you can start getting into the detail of what you're building. Even on a project that has been scoped carefully, it's astounding how much there is to be done once you get into the detail. I think this is where a lot of big projects go wrong: a sensibly scoped project can look a bit unambitious, a bit limited in what it's delivering, so people think they might as well do a bit more while they're at it. Once you get into the detail., it's suddenly unmanageable. In 2004 I was on a project based in New York that was on a three month delivery cycle yet consistently failing to deliver. Really, all I did was cut the scope right back. There was a certain amount of scorn on the project, not least from the development team, who, I seem to remember, thought we could do it all in two weeks. We did it just in time for the next release date. We repeated the process twice more and, when I finished we had a successfully delivering project and a happy user community. It wasn't rocket science.
One final consideration. In our example, we're building a new kitchen but when that's done, we'll need to move all the kitchenware across from the old one. And we need to make sure there's room for that large steam-punk coffee machine. In system terms, I'm talking about data migration. You need to ensure the new system can handle your existing data and have a plan in place for moving it across. And rehearse that process, too. The worst project I ever worked on hadn't rehearsed its data migration. With a new system going live on the Monday, they kicked off the data migration on Friday night. By Sunday afternoon, only half the data had moved across. Rather than aborting, Monday saw this telecommunications company based in Britain with half its accounts on one system and half on the other. It was a disaster, operationally and from a PR perspective.
That's my guide to scoping then. Think about the big picture, don't be over ambitious. Simple, eh?
But in my last post I was starting a series of posts about why large IT projects fail. I had originally written a list of all the items I want to cover and this had gone missing. After I started sketching out this post I found it again and I was pleased to see I'd been consistent in what I see as the first thing to consider, and that is scope.
When I'm talking about IT or trying to explain it to non-technical folk, I often find that talking about building is a good analogy. So, let's imagine that you're going to build an extension for a new kitchen.
First of all, you need to consider the rest of your house. You might not be doing any work there but there's plumbing and electricity to consider, and the stresses on the existing infrastructure. This, then, is not the time to discuss whether the bathroom needs renovating although if that's being done at the same time, you need to make sure you aren't moving a pipe that you're planning to feed into the kitchen.
Similarly, then, for your new project, before you start talking about what it needs to do, what constraints are there? If it has to exchange information with other systems, how will that work? Have you checked whether those other systems have their own changes planned?
Next, focus on the essentials. What needs to to be done in this initial project? It might be sensible to defer considerations such as floor tiles, painting and decorating, and kitchen furniture. Sure, the kitchen might not be usable until these are in place but putting those to one side, you can focus on a manageable amount of work that is quite different in its nature. Your joiner is unlikely to want to sit in on a conversation about Italian tiles.
So, for your IT project, look at what needs to be achieved. Yes, you might want a letter printing facility but that's academic if your client data isn't right. Of course, you want to know that that will be a requirement at some point - you want to bear these things in mind - but for now you need to focus on the core deliverable. This enables you to keep your team smaller, which facilitates communication and eases change management. It also means you are less vulnerable to changes in requirements - you have a smaller target - and when those do arise, impact analysis is simpler.
Once you have reached this point, you can start getting into the detail of what you're building. Even on a project that has been scoped carefully, it's astounding how much there is to be done once you get into the detail. I think this is where a lot of big projects go wrong: a sensibly scoped project can look a bit unambitious, a bit limited in what it's delivering, so people think they might as well do a bit more while they're at it. Once you get into the detail., it's suddenly unmanageable. In 2004 I was on a project based in New York that was on a three month delivery cycle yet consistently failing to deliver. Really, all I did was cut the scope right back. There was a certain amount of scorn on the project, not least from the development team, who, I seem to remember, thought we could do it all in two weeks. We did it just in time for the next release date. We repeated the process twice more and, when I finished we had a successfully delivering project and a happy user community. It wasn't rocket science.
One final consideration. In our example, we're building a new kitchen but when that's done, we'll need to move all the kitchenware across from the old one. And we need to make sure there's room for that large steam-punk coffee machine. In system terms, I'm talking about data migration. You need to ensure the new system can handle your existing data and have a plan in place for moving it across. And rehearse that process, too. The worst project I ever worked on hadn't rehearsed its data migration. With a new system going live on the Monday, they kicked off the data migration on Friday night. By Sunday afternoon, only half the data had moved across. Rather than aborting, Monday saw this telecommunications company based in Britain with half its accounts on one system and half on the other. It was a disaster, operationally and from a PR perspective.
That's my guide to scoping then. Think about the big picture, don't be over ambitious. Simple, eh?
Subscribe to:
Posts (Atom)