A few years ago I was in France, enjoying my summer vacation. I rented a car and drove around in the beautiful landscape of southern France. A very peculiar situation took place while driving through a small village; the car in front of me stopped and blocked my way forward. The driver in the other car jumped out and approached me. When he was up close he asked, in English, if I knew the direction of another small village. I actually knew the direction, but I was so much taken by surprise, that I couldn’t communicate it clear. I hesitated a few seconds. The other driver shouted something like “damn you French people, why can’t you speak anything but French” and returned very upset to his car.
What I experienced back then was similar to what I sometimes experience in projects, where the business analysts and developers try to reach out for each other, but assumptions are blocking the way forward. Sometimes there is a clash of beliefs in how to approach a project, gather the requirements and develop the system.
It is crucial for your chances of project success to solve these conflicts.
Three of the dominant roles in IT projects are shown below (these roles are taken from the Rational Unified Process – see: http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process)
- Business Analyst
- Software Architect
- Implementer
The majority of the activities for each role lie within the disciplines shown below:
A challenge here could be that the Business Analyst is gathering the requirements and business analysis but the Software Architect is the one going to design the solution, based on the deliverables from the Business Analyst. In other words they need to understand each other and they need to agree on the content and quality of the work. It will not work if the Business Analyst delivers state-of-the-art work while the Software Architect does not understand the material produced or (even worse) disregards the work produced and creates his own requirement and analysis. Does it sound unlikely to happen – I can ensure you, it is not.
What I usually recommend in order to deal with these kinds of conflicts is to avoid “over-the-fence-deliverables” where you simply deliver the completed work, hands it over to the next Role/discipline and steps out of the process. Instead, try to develop the work in cooperation. For instance you could develop the use cases up to a 50% completeness and let the supplier take them from 50% to complete, in cooperation with you. Or, you could let the Software Architect on an early stage review the work being produced and you could review the deliverables form the Software Architect ensuring that the design fulfills the business requirements.
Below I have illustrated the handshake you need to obtain – the Business Analyst agreeing with the Software Architect (or supplier, or any other receiver of the work) how to cooperate in the grey area between business requirements and solution design. If you don’t get that handshake your project is challenged. Be aware that it is usually not enough to agree on something high-level written approach – make some real examples and to a proof of concept.
I am not saying that you should accept your state-of-the-art requirements material to be transformed into something you do not feel comfortable about. But, if the receivers of the material do not understand it or choose to disregard it (it happens) – then you must address that issue.
The figure above is a nice way to quickly determine if your requirements approach is on the right track. In quadrant 1 you have a receiver of the work that understands the use of use cases (in this example it’s use cases, but could be any requirements deliverable technique) and the receiver is accepting to consider the use cases as the true requirements for the solution. This is the preferred situation, and you have the foundation for starting the project successfully,
If the receiver of the work accepts the use of use cases as the true requirements foundation for the project, but doesn’t have a clue about how to use and read use cases you are in quadrant 2. This is challenging your project. Depending on the receivers use case skill level you should try to educate and facilitate the process so that the receiver is guided forward – for example by introducing use case workshops and accompanying the use cases with proto types. If you are in quadrant 2 you should expect a considerable amount of extra work to end up at your internal business analyst team, and you should adjust your project economy to address that.
In quadrant 3 you have a very undesirable situation. The receiver of the work has the correct skill level but refuses to consider the use cases as the true requirements foundation for the project. Maybe the developers prefer to be agile without reading any requirements specification at all; maybe the Software Architect likes to gather the requirements himself, by talking directly with the end users. This means war. You will end up spending a lot of hours fighting and discussing. If you are in quadrant 3 you should consider if the project is better off being closed or postponed. Alternatively you could consider making a compromise by creating another concept of requirements foundation that satisfies both parties. Quadrant 3 is poison for your project especially if the project in the first place is risky and/or complex.
Finally Quadrant 4. Don’t go there. It is as simple as that. Your project is likely to fail in terms of not fulfilling
