Think globally act locally – this is the best solution for PM’s and client’s nightmares.
For those who’ve been involved with software projects for some period of time, these or similar kinds of situations may seem familiar. Let’s see:
- Situation 1: Your team is writing a piece of software for a client. The client now decides he wants to include a new feature, so the client talks to you about this and it’s obviously a complex and expensive new feature, but he is absolutely sure he wants it. You agree to do it and your team gets to work coding. It is done on time and within budget, your client is totally excited.
But later it turns out that nobody in your client’s team is using that new feature. What is even worse is that they are using another one, which is much faster and easy-to-use.
- Situation 2: Your team is working on developing a batch automation module. Your team is strong in Linux and, since batch scripts are perfect for automation, you know what you have to do. Several batch scripts and a few cryptic cron expressions later, you have a working solution. It’s delivered, installed and configured. Everything looks good.
But one thing that was set aside during development, and this was the fact that the client’s entire IT Infrastructure is based on Windows, therefore their tech team is trained in Windows. Can they maintain your scripts? So what happens is that in a few months they stop using it, and create their own solution they’re more familiar with.
So let’s talk about these points. You’ve delivered all the projects on time, and in absolutely according with spec. You might say they were really successful, as all the tasks were fulfilled. But if you think about it one more time from the client’s side, will the answer be the same?
Time and money were spent, but in fact, these projects didn’t actually solve client’s problems.
Do you think these clients would contact the same team for other projects they would have in the future?
Do you think they’d give them recommendations or testimonials?
Whose fault is it?
Every business-oriented developer, who has just experienced such a failure, instinctively wants to blame his short spoken client, while the client is about to blame the developers.
But it takes two to tango. A truly successful project is always based on good teamwork.
The question that needs to be answered is ‘What can I personally do to avoid this form happening in my projects?’
What should be done?
The only way to release a good project is to approach your work in a way that it is totally under your control. Your role in the team doesn’t really matter, you can be a team leader, PM, designer or junior developer, but all of you are expected to do this – not just to look through your tickets and code, but to think a little more globally, what does your client actually need.
So try not just to code, but to think out of the box/ticket.
By simply implementing what your client asks with no questions asked, you may be depriving your team or your client of your expert opinion and insights about the best way to move forward. I’m sure you’re often likely to have brilliant ideas of what’s good (new design, features that are easy to maintain, etc) and what’s bad (pitfalls, some side-effects, etc) to implement.
And who knows, maybe by looking at the problem, you can come up with a few better solutions which the PM or even the client have completely overlooked. And they might like and support your ideas.
How to do it?
Here are a few questions you can try to ask yourself the next time you get a ticket or a project:
- What does your client really need to get as a result?
- Are there other ways to achieve the goal, which probably are faster/cheaper/ more effective?
- Do you have any thoughts about the best solution of your task?
Just remember that when you get a ticket/project, you are not just coding. You are creating something that can bring your client comfort, and your company – a new long-standing client. You are a part of a team and close collaboration is the only way to reach success.
No matter what role you have in your team, this approach will bring your project closer to being a truly successful one.
All it takes is a willingness to ask questions and understand the reason the spec is the way it is. By understanding why it is the way it is, you put yourself in a better position to deliver what your customer truly needs.