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. [...]

Beyond Culture – Book Review

What these books are about
A set of studies about the deep meanings of culture. Edward T. Hall has lead a unique study in order to understand the consequences in our lives of our education. These books are not the latest available on the subject. Authors like Hofstede, Trompenaars or Lewis have produced more recent and maybe thorough studies. But T. Hall work is still worth reading if you are interested in the field of cross-cultural communication. These were the first books I read on the topic of cross-cultural communication. And I must say, they have saved me from a lot of frustration!

The Review
Edward T. hall has studied in a unique way the impact of culture in your daily life. Culture, doesn’t mean books or movies or even songs but is defining the part of yourself that you don’t really master anymore. All these reflex that you consider as natural are specific to each culture. They make you behave and think differently in front of the same situation if you are German, French, American or Japanese. It sounds obvious but it is not and Hall has driven an impressive study over the years which should be read by everybody living in a multi-cultural environment.
Once you have read these books you will never react the same way in front of your colleagues or friends coming from another culture. It should help you to avoid useless conflicts mainly caused by misunderstanding. Not that Hall is giving the explanation to everything but he is studying generic questions as: What is being late?; Are we doing one thing at a time like the Germans and the Americans or several at a time like the Arabs or the [...]

  • Email
    Permalink Gallery

    3 email management techniques for offshore software development

3 email management techniques for offshore software development

Keywords: Offshore Software Development, Project management, Communication, Email

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.

We will present solutions to reducing these risks:  delaying all sent emails, a safe email protocol agreement, thread management. This article is the part #2 of a series. The previous article in this series is available there: Keys to avoiding conflicts in an offshore software development project – Part 1.
The Risks
Do you remember that email you sent fast because you were upset, angry or simply in a big rush? You know? …the one that came back in your mailbox with a big nightmare attached to it!… Well, it happened to us all and is likely to happen again. It would be nice to avoid the next one, though.

In a cross-cultural configuration like in an offshore software development project, the risks are much higher: a word badly interpreted, a tone misread, a joke not universally funny, etc. The problem is even worse as most of us are not even aware of the risk. We all believe that humans are humans and that we basically exchange the same way by emails. No, humans are not all identical and they certainly do not read emails with the same eye as yours. Interpretation is everything; we will see that in the next article of this series.

And what about that other email containing the new agreed deadline? It was …when you were talking about how to recruit a Graphic Designer. This quote must be somewhere, correct? Unfortunate that the last 3 search you made did not show what you [...]

  • Fast communications
    Permalink Gallery

    Keys to avoiding conflicts in an offshore IT project – Part 1

Keys to avoiding conflicts in an offshore IT project – Part 1

A new series of articles
I will start today a series of articles on the topic of conflict avoidance within a Software project, and more particularly within an offshore IT project involving international team members.

As soon you put people together to achieve a common goal, the best and the worst can and most likely will happen. The power of achievement of the group is almost infinite. Unfortunately, the power of conflict and misunderstanding is almost as big.

In this series of articles, I want to present various common obstacles in the life of a project team and how to avoid them. We are not doomed to conflicts. But good will and best intentions are not enough. One needs to realize and truly understand what is happening and see the forces in action, to be able to act on the situation and convert the bad into good.

This article is hosted on my company’s website: http://www.liemur.com/keys-to-avoiding-conflicts-in-an-offshore-it-project/

 

 

  • 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 [...]

Brand new Blog Look and Feel

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.

I hope you like it. I can now return to my next article…

5 Truths about Communication inside a Project

Introduction
We are living in a world of communication. New fortunes have been made on the back of communication: Facebook, Twitter, Skype, Pinterest, LinkedIn, etc. to name but a few. It has never been easier to communicate! …Really? Well, it has never looked easier to communicate. But is it really as easy as it looks?

Easy communication is a kind of mirage, a dream we all would like to be true. If the means are indeed easy to use, it does not mean that communicating properly is easier. It is even probably the opposite: because it looks easy we do not think about it and we communicate badly. And bad communication is the source of many costly mistakes inside a project. This is why we are going in this article to review a handful of truths about communication.
Communication within an International Project
The context in which I thought this article is mostly within a Software Project. It remains true in most projects though. I have experienced these “Truths” and their positive or negative effects first hand. I also have experienced them within International contexts, such as an offshore software project. Keeping them in mind has saved the day often enough to be mentioned. If today, with Liemur, my company, we are offering near-shore software development, it is because we master these principles (plus many others that are not in the scope of this paper, of course). Far too often, projects are put in danger because of poor communication. People are always trying their best. It is rarely the intention that went wrong but the perception of the action.
1: Written communication is weak
Truth #1: To communicate efficiently, one must combine written communication with [...]

7 keys to outsourcing your IT project offshore

Here is an article posted on my company’s web site Liemur:

 

Selecting the right offshore company can be puzzling, especially if you have little idea where to start from. So, here is a short list of questions to ask yourself before you jump into the nearshore/offshore adventure.

More…

  • Project Success
    Permalink Gallery

    A Pragmatic approach to Software Process: UP + Critical Chain; Applied to a Retro-Engineering fixed-price project

A Pragmatic approach to Software Process: UP + Critical Chain; Applied to a Retro-Engineering fixed-price project

Software Process is great topic for endless conversations (and battles) among IT professionals. Every now and then, a new process is arriving on the market that is introduced as the new marvel of the world, the new silver bullet, thanks to which every software project is going to be a never seen before success. We can name a few:

Waterfall
V-Model
Prince 2 (although this one is not really an IT project process)
Unified Process
Agile family

eXtreme Programing
Scrum
Cristal
DSDM (Dynamic systems development method)
Kanban
Lean
Etc.
Etc.

During our decades of projects experiences, we have encountered many of these processes, used on various projects and in various circumstances. Today, I would like to talk about a project during which we have used a combination of a “proper” (in the sense of created with this purpose) software development process and a more generic project management approach. The two processes are:

The Unified Process (also known as Rational Unified Process, before IBM bought Rational) created initially by Ivar Jacobson, Grady Booch and James Rumbaugh.
Critical Chain, created by Eliyahu Goldratt

 
The Unified Process
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.

One of the most interesting elements is the Phases as they describe periods of the project during which the objectives are different. The first phase, the Inception is about scoping the project, identifying a possible architecture and listing the risks to come. Then comes the Elaboration phase, mostly about validating an architecture, [...]

  • 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 [...]