Software Requirements and 6 Thinking Hats

When in doubt: challenge the dodgy software requirements feature!
Writing software requirements (specifications) is a tricky business. On a project, there is a key role for that job: Business Analyst. They interact with the Business side and the Technical side. They are the bridge between two quite separate worlds. They are under tremendous pressure because they need to explain to one world what the other one wants. This requires, in the first place, understanding what the Business really wants. And sometimes, answering that basic question is difficult. There are several possible reasons for that. We could mention: difficulty to translate the business into computing routines; the difficulty to express without ambiguity a process that requires some level of human judgement, the business persons capable of telling what is needed are rarely available, there is no clear requirements process in place, the requirements capture format is fuzzy and not properly used, etc. But in this article we will study only the simplest one of them: The business may very well be simply unsure about what it wants. At the start of a project, it is quite common to make a long list of needed features. In this list, there are items that are obviously truly needed, and some are actually far less obvious.

I remember working on projects where some requirements were considered as mandatory, essential. One could not live without them. And when I was asking the simple question: who needs them? I could not get any answer. So, I then ask: who captured them? Still no answer. Nonetheless, someone, one day, believed it was a very nice feature indeed.

In some other cases, time is essential. The project must be released at a specific date. [...]

By |April 9th, 2013|Software Development|3 Comments|
Read More
  • Communication with the team
    Permalink Gallery

    The Language of the Receiver: Why best intentions are not enough

The Language of the Receiver: Why best intentions are not enough

When you are project manager, you are like the conductor of an orchestra. You must have talent yourself and you need the talent of others. But to make a success, you not only need everyone to have the same score sheet, you also need everyone to share the vision of what the group is trying to achieve. This Vision might very well not be coming from you. You can have been hired to implement someone else’s vision, but in all cases everyone needs to understand the goal. You can be producing Liszt’s Hungarian Rhapsodies, but there is quite a gap between a version for a cartoon and a version for illustrating the way it could have been played at the time of Liszt. Still the same score and the same artists in the orchestra, though.

Sometimes, sharing a Vision sounds trivial but it is not always. The reasons can be numerous. Here is one of those situations…

I once was working on a pretty big software project for a customer that had some of these communication illnesses I like to cure (I mean the project has illnesses, not the customer ;-) ). Let me tell you about the symptoms and how they exemplify some of the language challenges topics I have presented in this blog.

The IT project team has over 20 people. This project is absolutely key to the business and there is no question about the status of “flagship project”. The project is presenting a double challenge to the organisation, not only they are starting one of the biggest project they ever had, but they have also decided to adopt a new software development process. They have decided to adopt Scrum [...]

By |March 14th, 2013|Communication, Language, Software Development|0 Comments|
Read More
  • confrontation1.jpg
    Permalink Gallery

    Human dynamics: 3 IT Project Common Human Mistakes and How to Avoid Them

Human dynamics: 3 IT Project Common Human Mistakes and How to Avoid Them

 

We often talk about common problems occurring on a Software project such as not having the business executives on board, recruiting the wrong Project Manager, having too many projects running at once, etc. These problems are true and valid. But what I want to talk about today is a small list of more Human oriented problems; the kind of problems that are happening without anyone really noticing, and for that very reason, very dangerous ones. For simplicity matter, I will stick to only three Software Project Management Mistakes in this article.
Making too many assumptions

Human beings are communicating with unique and extraordinarily rich medium: natural language. We use it every day in every circumstance to sort out any problem. But using words to communicate ideas and concepts is also very time consuming. As a result of that, because we are efficient, we make many assumptions about what the people we communicate with already know. For instance, if I say to a friend that I was driving 50km/h on the motorway or 180km/h, I do not have to explain that it is very slow or very high speed. With the slow speed, this person will immediately imagine that I must have had a good reason for doing so: traffic jam, fog, heavy rain, car problems, etc. I can assume that the person I am talking to knows that there is a speed limit on the motorway and that the speed limit is say 130km/h. I can also assume that this person knows how drivers would usually drive in the country I am, if speeding is common practice or very rare. I could even make assumptions about the knowledge the person I am talking to, has [...]

By |November 19th, 2012|Communication, Human Dynamics, Language, Software Development, Team Building|1 Comment|
Read More