What is not included

We’re very fastmoving toward deployment in one of my implementation projects and I find myself spending more and more time clearing what is included but more importantly what is not included in the project. But this is not just stating the mere fact “this is not included”, you need to know what the status of the issue is. In my experience, if you just leave it as not included, it will come back and bite you when it hurts the most. In order to avoid unnecessary pain, you should ask the next questions. Let me draw you the scenario.

– We really need X. This is included, isn’t it?
– No.

This gives room for that nasty bite later on. What you should do is say why it is not included. Was it cut and who made that decision? Was it never meant to be included and why? Is it planned for a later delivery? Or have no one mentioned this before?

The fifth habit can here help. Tell the person the facts of the situation but then it’s time to listen. You should ask why it is important.

The next step is to establish ownership and an action plan. Does the person in front of you take for granted that you’re responsible for this issue from now? Is that ok with you? If you’re not responsible, make sure that you share an understanding of who is responsible and who will talk to the person in question. It can also be s good thing to have an idea what the next step for the responsible is. Is it writing a change request or conduct an investigation?

Before you end the discussion, repeat that it’s not included, who is responsible, who will talk to the responsible and which next step we suggest.

– We really need X. This is included, isn’t it?
– No. We never planned to do this in this project. Is it important?
– Yes, we have C in two months and we need it for that.
– I didn’t know that but I don’t have the time to change this now. This could perhaps be handled in a change request. Who handles the change requests for this area?
– J does that. But there is no change request about this.
– Could you write one and send that to J?
– I don’t know how to write change requests….
– I can send you the template and when you’ve tested it, get back to me if you need help.
– Ok
– This means that this is not included in the delivery but a cr should be written. i’ll send you the template and then you’ll get back to me if you need more help before sending it to J. ok?

And finally, don’t forget to mention this the next time you meet in order to secure that there still are misunderstandings.

There is no No Rules situation

Many years ago, me and my husband visited a New Year’s Party, which has stuck to my mind for many reasons but one was that there was no dress code in the invitation. We were a bit confused but dressed up a little bit but chose outfits which could be adapted to a more slack situation.

When we got to the party we could see that we hadn’t guessed wrongly: this was not just a casual dinner.

Everyone was enjoying themselves expect for one guy. He had taken the “come as you are” statement literary and wasn’t wearing a suite. He felt he didn’t belong and he left as soon as he could have. Other people in similar situations tend to get themselves drunk instead and just a few don’t care. We like to fit in.

There are many situations at work (at least here in Sweden) where you are told that there are no rules. You can do it how ever you feel fit. But in many cases this is not true. There are untold truths, acceptable options/non options in many situations. If you’re lucky, you have a Commander’s intent and/or a good manager to guide you, but if you’re not that lucky you end up being the only one not wearing a tux.

If your department or project have these untold codes and rules: Get Them Into The Open. By saying that there are no rules you are up for disappointment and worries.

So what do the good leader do in situations like the new year’s party. Well, first of all you should never not have a dress code to such an event but would it happen, the good manager takes of his jacket too so that the lonely guy is not that alone anymore.

Now you probably wonder what blunder I’ve done at work but the truth is that I’ve been invited to yet another Christmas party without a dress code. I think I’m going as Darth Vader.

In the middle

I’m currently in the middle of a small (2 months) but important project. I wouldn’t say that we’re following a specific software development method but instead we try working after a few principles, which are maturing as we work.

1. Clear decision maker.
The developers know that there are so many business people involved but there is only one decision maker.

2. We talk every day.
At least once a day we talk. That does not mean a formal meeting. Sometimes it’s many small gatherings, sometimes it’s a formal meeting in a conference room, sometimes I call the developers one at the time. But we talk every day.

3. Status updates to key business people at least once a week.
This is not necessarily the managers but all who are affected by the project in their daily work. They are always informed on current status and we can repeat information on what is being delivered.

4. We don’t do stuff which takes long time.
We’re on a tight schedule so every hour count. If someone gets stuck, he need to address that at once.

5. We only do stuff which we have a good feeling about.
Since we are on a tight schedule, we must be careful not to do things in a bad manor. This does not mean that all solutions are the most refined. They are supposed to be the best ones, given the circumstances, but if someone feels uncomfortabld with a solution, we should avoid it.

6. At least one developer on business meetings.
We have many and short meetings with the business and include the developers. They are better at explaining what they are doing than anyone else and need details on requirements than anyone else.

7. Sleep on it.
If something seems unmanageable, we try not to decide directly but instead sleep on it. Many problems have just handled themselves.

8. Take the time to explain.
When someone has an issue with something, we try not address this in big meetings. Instead we take the time with more one to one meetings. Here is empathic listening crucial. But also clarity about what is important from a wider perspective.

9. Build on trust.
The basic principle is that we trust each other, that we act as someone to be trusted and that we build our solutions on that. This does not mean that we don’t follow security regulations but rather that all solutions should not be based on the assumption that co workers cannot be trusted. Instead we protect what is very important and explain our solutions in order to clarify how things work. If it turns out that someone is breaking the trust, this is a bigger problem.

10. Have fun.
We try to spend as much time on things that are fun to do. Creating functionality which help our customers is fun. Creating functionality which helps our business is fun. Clearing out misunderstandings is fun. Delivering a release which we can be proud of is fun.

As I mentioned, I wouldn’t say that we use an agile method but instead we work with an agile heart.

Positively stupid?

Is it a good thing to be positive? On a first glance at the question, the answer is YES! You become more successful, happy and your health improve. Victor Frankl also shows in Man’s Search For Meaning that focusing on what is possible is an important factor for survival and personal growth. But there is also the findings from Jim Collins Why The Mighty Falls: the first and third stages in the death of a successful business are Hubris and Denial of Risk. These stories tell about companies who think they are doing the right stuff and keep thinking so until the bankruptcy is a fact.

There is a fine line between seeing what is possible and believing in the impossible.

In the book, Smile Or Die, Barbara Ehrenreich discuss this misinterpretation of the notion that seeing the opportunities is the same as being positive about everything. Instead, her meta studies show that people tend to be over optimistic which makes them turn the blind eye to risks. Much the same as Jim Collins shows, in other words.

I will probably never look at personal growth books in the same way again.

When I look at software projects, this positive thinking virus is everywhere. Of course you shouldn’t start a project if you don’t believe in it and of course you should help build confidence in success in co workers in order to make them succeed with their tasks. But overly positive thinking can bring the downfall too. Here are some common examples:

1. Estimation

“This shouldn’t take more than 4 weeks/hours to do”. Some think that some things SHOULDN’T cost more than a certain amount and therefore they change the estimate in order to suite their notion of what a reasonable price is. An estimation should be based on how much time it takes, not how much time it’s supposed to take.

2. Good is the best enemy of Best

“Why are you questioning X, we’re making Y M [Currency]?”. The notion that we’re good as we are makes it hard to really improve. But even if X is enough right now, the competitors are just around the corner and historic successes is no grant for future ones. Just look at the current state of the companies named as successful in From Good To Great.

3. Denying risks

“But that never happens….It just happened three times last week. It will never happen again.” No wonder that Deming talks about an error as an error and an error many times as a system error. But many seem to fail to understand that just because an error is not supposed to happen makes it not happen. And it happens many times, why would this result in it never happening again?. This is also applicable in planning: “Well, we’ve lost all the buffer during the first half of the project, but we’ll make that up now.” This probably happened. Sometimes. Somewhere. In another dimension or something.

4. Kill the Happy killer

“Don’t say that, people get unmotivated”. Yes, there are whiners, those who just whine for the joy of that, but a culture where it’s bad to question the current status in order to bring an improvement is probably not the best one you can be in. I’ve heard many who are afraid to suggest improvements because they are afraid to be perceived as negative. We must all learn to differentiate between negative and positive about improvements.

Do you have any other situations?