Agile Lab - Training, Coaching and Consultancy Blog

Saturday, 5 December 2009 at

3 Reasons NOT to do a Web Development Project

If you've come to this page for whatever reason and you don't work on a web development project, I hope you don't mind if I ask you to leave. This is really private stuff, just for people who try to make websites for a living. Here are some other interesting posts on this blog which aren't quite so private, personal and painful: "What is agile?", "Why is it so complicated?".

OK, now it's just us. These are three reasons (excuses actually) for doing web development projects which I hear a lot. They can all be prefaced with "We're doing this project, even though we're losing money on it because..."

...this is a big name client, a famous name and so it would be good to have them on our client list.


But they're treating you really badly right? You find yourself doing about twice what you would do for any other client just because they're a big, famous name and you want to please them. If you have relationship like this with every big name client that you work with, how long are you going to last?

...this is only a small (money) project but there will be bigger ones from this client in the future.


This might be true. But this means that you have to especially careful to get the balance right between the value that you give to this new client and the money you charge. There's a terrible temptation to bend over backwards to please your new client, in the process losing money and even worse, setting their expectations for your relationship for the future.

If you are being extra nice to them because they're a new client, make this clear that that's what you're doing! Make it clear that you're giving them an introductory rate or a 25% discount or whatever. Use this small project as an opportunity to understand your client - and identify any potential problems. Could you really work with them on a bigger project?

...we need this project just to keep busy and get some money coming in the door.

Ouch, ouch, ouch. And that's just when it's written down. When you actually hear the pain in someone's voice as they tell you, essentially, "We're taking on this money-losing project because we need the money." Oh dear. Hard times. Tough choices. So what can you do, if you really do need the money? Well, one thing is to make the discounting that you're doing explicit. This gives you much better scope for charging your full fee later on any further work. Another, even better option, depending on the sophistication of your client, is to offer a high-quality, reduced scope, full-price solution e.g. "we can't give you the bespoke site you want for that money, but we could skin a wordpress site that gives you 95% of what you want."

But finally. This is the hardest alternative. If you don't think you can make money from the work, don't take it on. As the Zen master said, empty your cup so that it may be filled. Use the time to finish any work-in-progress that is lying around and get it finished. Use the time to improve your processes. Use the time to talk as a team about what the recurring problems are with the work you do, and to suggest possible solutions. Advertise to existing clients and potential clients that you can now take on and deliver work at short notice - for a premium!

Oh and of course. Get some training. I can do it at short-notice for a premium ;-)

If you liked this blog post, you might like these: "I'm your software developer and I'm listening", "John Seddon's Re-thinking Lean Service", "The Value of Something"


For further information, contact mark.stringer@gmail.com (07736 807 604)

Labels: , , ,

Tuesday, 1 April 2008 at

Pitcher's Poker - Part 4: The Other Side of The Table.

How does all this look from the side of the customer?

Well, I'm the customer. We looked at 6 pitches. Surprise, surprise, they all looked great. Music, visuals, promises, promises. But unfortunately, I've been here before, I've seen fabulous pitches in the past and selected the company with the most fabulous pitch. That project cost us a lot of money – twice what we budgeted for it. In the end it got canned. We don't talk to that company any more. In my head, now, when I think of the budget for some new web project, I'm thinking – yes, but that's actually going to cost three times that isn't it?

So this guy turns up. He doesn't have a laptop. He doesn't have a pen drive. He doesn't have a presentation! He has a flip chart and a marker pen.
“In one sentence, what is it you want?” He says. There's four of us watching the presentation. It doesn't make me comfortable that we all say four different things. He writes them all down.
Now things get really weird.
“Who's the pig?” he says.
“We beg your pardon” we say.
He explains the difference between pigs and chickens. It's like bacon and eggs. The pig is committed, the chicken is only involved.
“Who's the pig?” He says again. Who's bacon is on the line? My boss starts preening himself. But the finance director and the HR director point at me. My boss doesn't say anything. They're right. It's me.
He makes me put stars next to the four things on the flow chart. Then he draws a ring around the two with the most stars.
“Give us X amount of money and we'll demo something that does these two things by the end of next week,” he says.

Then he picks up his flow chart and leaves.

Labels: , ,

Monday, 28 January 2008 at

How to avoid 'too many cooks spoiling the silicon broth': an approach to making public and third sector multi-agency IT procurement work better

Most public sector IT procurement is multi-agency. This means that a ‘partnership’ or ‘collective’ of organisations or departments are given the task of defining needs and outcomes for an IT development project and then managing its delivery, role out and support.

The job of defining what is needed for an IT build, re-build or next stage development is difficult enough if a single agency is responsible for it. This is because needs, legislation and technology change continually. Add to this a multi-agency client and the best case scenario is one where perhaps part of the commissioning group get part of what they hoped.

A lot of projects however don't turn out for the best. In many cases the project will simply fall apart leaving a legacy of wasted public money, broken and unusable systems and tattered relationships both within the procurement group and with the developer. This can still happen, even that everyone was trying as hard as they possibly could and a recognised project management method like Prince2 was used throughout.

Some of the reasons that multi-agency IT procurement fails are:
Expectations and needs are rarely fully revealed and unpacked sufficiently to avoid misunderstanding between agencies
IT solutions are often expected to provide miracle cures to inter-agency working that are really cultural or people problems
Rigid implementation of big clever designs allows little room for changes to requirements to be added or systems to be developed in such a way that they can cope with change effectively
It isn’t until the thing has been developed that people realise that that wasn’t quite what they needed

These problems can be avoided and addressed through the adoption of methods that have worked effectively elsewhere in the IT industry. Such methods do not need to replace the methods that the government wants to see used for development (Prince2), but they can compliment Prince2 to provide new tools to fix common problems. These tools come from the group of methodologies known as Agile.

Agile takes a different approach to the process of specifying development needs and outcomes by placing much greater emphasis on defining the exploration and prioritising of such needs and outcomes through common language and thorough exploration. Agile also assumes that change is constant and therefore is the friend of IT development rather than the enemy waiting to derail well intentioned projects. But most importantly from the point of view of multi-agency procurement, it can be applied very effectively to ensure that there are no hidden or unrealistic expectations hiding in the specification or the contractual and design documentation that will lead to development failure.

Agile Lab use facilitated story writing workshops to help multi-agency teams unearth the potential problems before they become real problems. We also use workshops to help get derailed projects back on track.

We believe that the people involved in broken multi-agency IT procurement, whether the supplier or the supplied are generally well intentioned and will try the hardest. However, this alone is not enough. Without the right tools for the job problems will fester and can lead to disaster. We can help get your project back on track or heading the right direction quickly, saving you money, time and stress.

Get us in and get on!

Labels: ,

Thursday, 27 September 2007 at

There has to be a better way of getting software developed

Why is it that many people have had painful experiences of procuring software? You would think this should be a wonderful opportunity to engage in creativity and innovation, to learn something new and see some of your ideas become realised in ways you could not quite imagine. But the reality turns out to be completely frustrating. You don't get what you want or what you were promised, you get it late, over budget and it never works properly. Then you find out that what you just paid said web tech company many thousands of pounds for is available for free on the internet anyway!

The fact is that paying for software development at a time when technology is moving so fast will always be a risky business. Ironically, despite the painful stories and battle scars of those that have had bad experiences of software development procurement, much of the problem can be put down to the processes that are used. If you are paying for development then the perception is that you want to know what it is you are getting before you sign a contract. Therefore you work with your supplier to develop and agree a list of functional requirements. These are costed and their development is plotted on a some kind of time-line with milestones, deliverables and so on. Then you press the go button and in theory everything works out as planned. Or, as is more likely the case you end up cutting requirements like crazy to make deadlines, getting half-baked functions that kind of work but not really as you had hopped and the rest is history.

So if this Agile malarkey is so great then what could it do to this process?

Agile provides the software purchaser with a suite of methods that can help them get what they want, when they want it and on budget. However, for this to work it requires a potentially seismic step outside of the comfort zone of a tight requirement list and schedule into a space where creative thinking and constant change are embraced jointly by the supplier and the supplied in order that everyone gets what they want. The supplied gets great software and the supplier gets to make some money and you are still on talking terms at the end of the project.

This works by the supplied selecting who they work with on the basis of who they want to work with because they understand the problems faced in the environment the software is required for, have an attitude and approach that gives you confidence that they can deliver really good code and can talk to you in a language you understand. 'Ahhhh', I hear you say, 'but we do that and still things end up pear shaped'. Yes, but despite having these feelings towards said developers, you also probably made them sign up to a fixed set of requirements and specifications and a tight and rigid development schedule so you were asking them to work with a big fixed design up front and a deliverables time frame that required first this, then that, then we pay, then you do this and then and then and then. And then it didn't work out like that.

If you were working in an Agile way you would be only taking one step at a time and according to a continually changing requirements list. You would be able to add, change and re-prioritise your requirements as you go so that you were always addressing the real needs of the project rather than a set of needs that made sense before you had any working code to play with. You would also be in a position to learn more about what your needs are as prioritised working functions begin to emerge rather than having to rely on very early sketchy ideas of what you imagine you will need before you really know.

Then their are stories. Agile uses narrative and dialogue between client and supplier, stakeholder and user to ensure that people really get useful stuff. Stories are much more effective than pretty pictures and technical descriptions. We can all understand them and that means that their use greatly improves communication around the project.

I could go on here. But I wont. I have been involved in enough projects that haven't gone smoothly to know that Agile makes a real difference. Given that much software development is paid for by the public purse surely it is time that those responsible for this expenditure start to look for more effective ways of working. Anyone who has been close to software projects in the public and private sector will recognise some of what I have written from their own experience so surely it is time that we innovate with process instead of using broken old fashioned approaches to software procurement that often leave everyone feeling dissatisfied?

Labels: , , ,

© Agile Lab, 2007-2009. All rights reserved.

sitemap

Powered by Blogger

Subscribe to Posts [Atom]