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.
Summary: Emails are so easy to use and so often used that we never think about them again. This article will introduce 3 dangers inherent to emails: immediacy, room for interpretation, crucial information storage.
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.
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.
I am glad to announce that I have updated the look and feel of my blog for a more modern and pleasant Look and Feel. It has been tedious to do so and I apologise to those who tried to access my site in the last 3 days, but that is what it took to do the switch.
The Unified Process (also known as Rational Unified Process, before IBM bought Rational) created initially by Ivar Jacobson, Grady Booch and James Rumbaugh.
The Unified process is not only a process but more generally it is a framework that has been created for being tailored for each project. It is the first iterative and incremental framework that has been applied widely in the industry.
It is composed globally of four Phases, each Phase being composed of Activities.
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.