As per our experience while working with Waterfall and Agile, upfront design doesn’t necessarily work and in all practical cases it’s rather evolved design which we need to target for. However the same may not hold true for project architecture. Though you’d like to change some of the implementation pointers in process, you’ll not think on changing the structure itself completely.
It’s a costly affair and may prompt you to rebuild the building from the scratch again. Sometimes this is the destiny of some failed software projects. And many a times, the root cause is – at the beginning of project, customer himself was not clear what he really wanted.
Yesterday I had an interesting discussion with Srini. It started with me telling a story of a mentoring session I had with my mentee.
Chapter I
That mentor session was all about knowing each other better so that accordingly we could plan out the roadmap of the things he’d like to do in near future. I started the mentor session with a simple question – “what are your strengths as a person and a professional?”
This is what he said about his strengths:
- An aptitude to work and pick up any latest technology
- Happy and friendly
- Calm as much as possible
- Speaks only when it’s needed
- …
With above mentioned points I couldn’t find some worthwhile pointers. These are very generic facts and don’t give you much to ponder upon. So to know something more, I probed further and asked about his passion. He said, “I like to work on new technologies”.
Oh… damn!!! That was not the result I expected I thought. With that answer, still I had no clue about his real passion and strengths which could be handy for me to identify his personality traits. “If I know his true persona, I’ll be able guide him in a certain direction”, I thought. But at that point of time, that destination was looked too far.
I decided, Okay, let’s go even deeper and started asking about his college days and what all achievements he made during those years in which he could do something which he really liked the most. After some further probing this is what came out:
- He was the head organizer of the tech fest held at his college and that effort was very successful.
- He did a research software project so that he could transform the voice of a person into some other voice based on already held deep research, formulas and algorithms.
- He created a software project which could convert a human skull into some recognizable human face which could to recognize the real person.
I was just awestruck as I never imagined that a person with a bit of lost confidence has traits which we never knew before. From then on… I knew, I could figure out the puzzle.
I said, “So you should be termed as technically strong person who enjoys deep technical analysis, algos and stuff like that which for a usual developer is not the cup of tea”. He said, – “Yes!”.
I continued, “Then don’t you think your passion is working with some challenging and deep technical stuff which deals with algorithms, deep research to know the unknown etc….?”
This time his face brightened up and he confidently and happily said, “Oh yeah…you are right. This is my passion!”
I said, “But you didn’t talk about it earlier”. “Yes… but I was not sure if you are looking for that. I was rather figuring out what all things I would like to do in coming days”, he said. Interesting, I thought inside. If it can happen to him it can happen to many others.
Chapter II
Back to discussion with Srini further, I continued, “It can happen to any customer also who has some vague idea about why he wants to execute a project but may not be very clear on what he really wants. So this kind of brainstorming I had with my mentee should similarly help a customer in figuring out overall objectives and the missing links of the end goals.
Srini agreed and he told me yet another instance…,”When we go and choose some ice-cream, sometimes we really are not sure what kind of taste we are really looking for. At those times, sometimes it’s because of others we chose a certain type of ice-cream. But confidently we are not so sure”.
“Similarly when we write some goals on the goal sheet given at the end of appraisal cycle, sometimes we fill the goals as they need to be filled in. Internally we may not be quite sure (as we didn’t probe deeply) if that’s what we’d like to achieve in next 6 months in the organization.”, Srini continued.
Conclusion
So coming back again, similar to these stories, why do we expect customer to know everything at the beginning of the project? When project fails (because for instance he recognized something else in between which he never analyzed before or he comes to know it at the very end), we some time term that as customer failure and say that he didn’t know what he wanted.
However with this analysis, I think it’s very clear that we as Consultants also didn’t try much to probe further from customer and we were just concerned and focused on the overall implementation.
I feel at the beginning of the project, enough time should be given both from customer and consultant’s point of view to just see what all we are trying to get from the project in overall business sense. Again that discussion doesn’t end at the beginning of project implementation. At that time of implementation, we may come to know many other pointers which may prompt us to think about project implementation from a different perspective.
For me, it’s important to be Agile in this perspective and weigh overall business goals continuously. If we really don’t worry at that time, chances are – the project is not used at all or not used to its potential.
This kind of analysis and effort provides avenues to know the business goals in real sense and also how they are related with architectural foundation of the project. With this aspect in mind, I hope we can expect to have more successful software implementations.
References
Martin Havemann says
This is very similar to my experience – the problem is that allthough the customer deep inside do not know what he wants, he is very confident in explaining what he WANTS and how he sees the world. However that is not necessarily what he NEEDS.
It is our duty to find ouy what he needs and not just give him what he says he wants – and that is true for both agile and waterfall methods.
Read more about it in on my blog here: http://commonsenseoryourmoneyback.blogspot.com/2011/10/user-is-never-right.html