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

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

The Project Management Coaching Workbook – Book review

Project Management is a daunting task. Whoever has been in this position will tell you that. This job is made of so many different activities that one could easily loose track of them. Easy to run around like a headless chicken!

Susanne Madsen’s book is a great reading for several reasons. Let me explain in this book review.

 
A book for getting better
In the first part of the book, the author goes through a guide to introspection. Why on earth do you want to be a PM in the first place? The question, for simple and obvious, deserves to stop a little while. And Susanne Madsen provides a few elements of possible answers or shall I say example of answers? She is guiding the reader gently on a self conscious thinking state that is the start of any greatness. But she also takes care to never give you the answers. They must be yours.

This principle of getting better is present the entire book long and as such definitely deserves its title “Coaching”.

 
A very pragmatic guide
At the same time, the book is going thoroughly through almost all the activities one can think of when talking about Project Management. As such, this will be an excellent guide for the junior PM who will have a proper idea of where he or she stands on that job. From planning to delivery via the relationship with the team or the sponsors I hardly see any left aside topic. This is definitely a book written by an experienced PM.

So you will be asked to assess yourself on all those topics and later on you will be guided on how to improve those skills.

 
No specific process assumed