Today at the 4Developers conference in Poznan, Poland, I presented the audience my concern about the existing gap in between client’s need and the reality of the software developers. For some reason we seem not to manage to understand each other well enough. Too many projects do not deliver the result the client was hoping for. Honestly, it’s no longer a question whether or not this gap has to be closed. We just have to do it to make software more successful and clients more happy. But who’s responsible to bridge the gap? In my opinion the software developers. I will try to explain why. [Picture source: Allaboutjazz.com]
Article Contents
Software projects fail too often
Based on many data sources and publications we can only conclude software projects “fail” too often, meaning:
- The project is not delivered on time
- The project is not delivered within budget
- The project is not offering the requested/promised functionality
A combination of the above is happening as well of course.
It’s not easy to improve but we just have to
Neither I’m going to claim I know best how to solve the issue. Honestly I’m learning every day of the mistakes we are making ourselves. As every other software company we have both successful and improvable projects.
Nor will I tell you it’s easy to bridge the gap in between clients/users and software developers. These are people with a different background, different interests and a different focus. Both communicate, think and express themselves totally differently. You could say clients are from Mars and software developers from Venus.
But one thing is for sure. We need to bridge this gap. Business will have to talk together with IT, it should neither be a continuous fight nor competition.
Are we willing to work together as partners?
To realize excellent software solutions a developer will need very well specified requests. Based on a quick poll among the audience and my own experience I conclude too often clients are just not able to really specify their needs. At least not in terms a developer will understand.
I don’t blame them because I believe it’s almost impossible to fully define your needs in such a way that everybody will understand it.
We will have to find another way of communicating the client’s needs. At it’s best developers are defining the needs together with the client. Several “best practice” or “Agile” methods are available to support this process.
It’s important that we define what the software application has to do in terms the business understands. When using Business Driven Development it would look like this:
Discussing the needs in this way will also lead to all kind of usefull user stories which will make the developers understand the needs better. Besides discussion will lead to more creative ideas! Together you can prioritize them. While prioritizing it will also become clear that currently too many useless features are being developed. By setting the right priorities together you can also safe a lot of money.
The next step would be to start prototyping. You can do this by means of wireframes, mockups, draft GUI’s etc. The aim is to show the client/user as soon as possible what it’s all going to look like. The instant user feedback will show the developers whether or not they are still on the right track. Communication is king in this phase. Developers should be willing to except changes in business priorities during the development. A user will better understand what he really needs once he sees the first prototypes and working releases.
Honestly, the method doesn’t matter, because it’s just a method. If the willingness to improve is there from both sides and when they invest time and effort in defining the project you can choose any method that suits you best. The cooperation as partners will be the biggest gain, period!
Developers will have to start this change
Developers their life will become a lot easier if they understand the client’s needs better. Therefore, they should make the first step.
And why wouldn’t you? Just imagine that you won’t have to fix “bugs” anymore and that the amount of unexpected change requests drops? How would that feel? I know it’s scary, but please just give it a try. What can you loose? Add some funk and have more fun making better solutions, may be even the best solutions.
But this doesn’t mean it will be easy. Especially when clients think in the traditional model of sending a request and agreeing about a fixed priced, fixed date project. Both sides will have to trust each other. The business has to dare to share their ideas and needs. If it’s hard for your development team to achieve this interaction with your client just start working like this yourself. One of the team members could “act” like the client. A sales person, consultant or business analyst are in general best for this job.
We try to achieve this level of trust by having many (in)formal meetings at the start of the project. Having a drink and dinner together makes you start acting different. Several workshops together show the added value of such an investment.
If we don’t change the competition will overrule us
Having a nice and relaxed 9 to 5 (or more common in Poland an 8 to 4) job you might not be willing to bother about the above. But software doesn’t stop at 4 pm. Clients are depending on software solutions 24 hours a day. And business dynamics are hard to plan.
If you are willing to support the business better this will demand an additional investment. You will have to spend time together, probably you should learn more about the business. That will take time, after hours.
But if you don’t do this, the competition is waiting. In China and India there are many young, eager and clever software developers willing to take our jobs. Today the main issue for the client will be that it’s even harder to outsource the work to these countries. But sooner or later they will find out how to use these resources if we as Polish and European developers don’t manage to seduce our clients.
[slideshare id=3568330&doc=4developersgoyellofunkysoftwaredevelopment20100326phofinalb-100326184144-phpapp02]
It’s not about methods, but about “funky” cooperation
Hopefully I managed to show we can not solve the current situation just by implementing a new “funky” method. There are more steps needed. I will summarize them:
- Get to know each other: Business en IT will have to invite each other to share thoughts, to understand each other
- Trust each other: The relationship in between Business en IT will have to be based on trust
- Stimulate creativity: Business needs should be defined together
- Make things understandable: Business needs have to be defined in an understandable way, as “user stories”
- Set priorities, exclude waste: The business sets the priorities for the implementation of the features
- Interact: Development should be more iterative and interactive based on prototyping
- Communicate: During the development we have to communicate, communicate, communicate
- Change is the norm: Developers have to be open to changes. Business needs will change over time
The above is a rough summary of today’s presentation at 4Developers in Poznan, Poland. Feel free to check the slides. I’m looking forward to your feedback, comments and opinions below. Thanks for your attention!
After my presentation @mesirii send me the following link where Martin Fowler and Dan North discuss bridging the gap as well.