Tone at the top

~ Andrew Stellman ~ Leave a comment

I’ve been doing a lot of work with Sarbanes Oxley governance compliance lately. It’s interesting how many similarities there are between what it takes to put good accounting and financial processes in place, and what it takes to do the same for software engineering. I’ve found that many of the core project management principles — transparency, honesty, “doing it right” all the time — which Jenny and I write about are very important in accounting and finance as well. So I guess I shouldn’t be surprised that we software project managers can learn something from our cousins in the accounting discipline. They’ve identified an important idea which I’ve encountered many times in software enigneering, but which I’ve never had a name for: “tone at the top”.

Essentially, if your senior managers don’t have the right attitude — if they don’t honestly support the idea of transparency and good practices — then that’s an reliable leading indicator that there are more serious problems down the line. You can fail an audit if the auditor finds that your company has poor tone at the top.

In an organization with poor tone at the top, the senior managers are simply unconvinced of the value of good practices. They will often reject the ideas of transparency, honesty and measurement. They run the organization based on gut instincts rather than sound planning, and they reject attempts at improvement. I suspect that the reason this is a more recognized and discussed problem in accounting than it is in software engineering is that there are codified ethics principles and more visible consequences. Poor tone at the top in a software project manifests itself in micromanagement or lack of leadership, which leads to project failure. That may sound serious, but in contrast, poor tone at the top in accounting manifests itself in ethical breaches and fraud, which can lead to shareholder revolt and even jail time for executives. If project managers could go to federal prison because they lied to their stakeholders about the project schedule, we would see much more transparency in software organizations.

The “tone at the top” problem may sound very familiar to anyone who has tried to put a good practice in place only to find resistance from the boss. A basic tenet of software project management is that a project manager has no hope of putting better practices in place if his company’s senior managers aren’t behind them. I’ve talked to many project managers who recognize that sinking feeling that they get when the boss — who previously said he was completely behind the PM’s effort — did an about-face as soon as he heard a complaint from a programmer or stakeholder about the new practice. It turns out that that’s a classic example of bad tone at the top. The next time I need to talk about that problem, I’ll have a name for it!

Getting started with use cases

~ Andrew Stellman ~ Leave a comment

A friend of mine is introducing use cases to his company, and asked for some advice. It sounds like an interesting project — they’ll be using it for both a hardware and software component.

Here’s what I told him:

  • Spend a lot of time talking about what’s actually going to be covered in the use cases up front, and try to stay flexible.
  • When you’re working on the use cases, there’s a good chance that you’ll spend some time talking to people and eventually think, “I understand now, I don’t have to talk about this any more.” It’s useful to learn to recogize that feeling as an indicator that you need to verify everything one more time.
  • Also, recognize that when you think, “This person doesn’t really understand this, but I’ll give them what I know they need” that roughly translates to, “There’s something here that I don’t understand, and I need to tease it out of the person.”
  • Don’t be afraid to scrap everything and start over. It’s a lot cheaper to do that now than after you start coding.
  • And don’t let anyone convince you not to do that one last review — that’s the one that will find the really BIG problem.

Great review from Knowledgtrain

~ Andrew Stellman ~ Leave a comment

Take a look at this review from KnowledgeTrain:

http://www.knowledgetrain.co.uk/project-management-training-course-article012.php

I think it definitely captures what we were trying accomplish with our book. I agree with almost all of his criticisms — for the most part, they are a reflection of decisions that we made about the direction of the book. (As you know, in any project of any reasonable size the team always has to make tradeoffs!)

I liked what he had to say about our writing style, which I really think is a strength of our book:

  • There are too many books about software project management or software engineering which are dry, overly complex and boring, but this book is not one of them. It was a joy to read because their style of writing is clear without being simplistic and the authors describe things in just the right amount of detail. It seems they understand their audience and set out to write in an extremely helpful and practical way. They have certainly achieved this.

And I especially like this part:

  • I would recommend this book to anyone who works on a software development team because the book has so much practical advice to help people improve their capability to deliver quality software. Come to think of it, I would also recommend it to senior managers of companies who have a negative view of their own software development teams. Perhaps then senior managers might understand why committing resources to process improvement is one of the best investments they can make.

Exactly! I’m really glad that idea came across — it was a point that Jenny and I really thought was important.