How to manage managers - Question 4 Jared and William

[Pat Dennis]

I had a look at the editorial review on Amazon, and I am very interested in hearing more about "How to manage managers, end-users and sponsors". Could you go into more detail on how your book covers this?

I have managed a software development team of 7 developers for 3 years and I have found that the biggest challenges isn't following a good development practice (XP, Rational Rose, <insert your favorite here>), it is managing the expectations of the business.

For example: You are the IT manager of a company, and the CEO says to you: �build me a widget (could be anything), and you have 4 weeks.�, and you follow your software development guidelines that means that the project will take 8 weeks. How do you manage the CEO in this case? What do you sacrifice, the deadline or your software development guidelines?

I think most managers and senior programmers will tell you that they have had a similar experience with this, and would love to have the skills to manage the managers.

Thanks,

Patrick

[Will Gwaltney]

Originally posted by Pat Dennis:
What do you sacrifice, the deadline or your software development guidelines?

Hi Patrick,

In the immortal words of Andy Hunt, "It depends". First off, you need to prove to your CEO beyond a shadow of a doubt that it's impossible to give them what they're asking for. But you obviously can't stop there; you have to give them alternatives. These usually involve slipping shedule, cutting back on features, or adding/re-allocating resources (contrary to popular opinion, sometimes adding more developers to a project actually does let it ship earlier).

If the answer you get back from management is still "it has to ship on time, and it has to have all the features, and you can't get any help from that ace developer down the hall", then you're probably going to have to sacrifice quality *in the short term*. (Truth and Beauty considerations aside, there are sometimes good business reasons to ship a product that is "good enough"). However, you should make it clear that the quality will suffer, and you should get management to agree that this is a *temporary* solution. Then immediately add to your project's To Do List an entry to rework the widget, so nobody forgets.

-- Will

[Jared Richardson]

I think that you are right. The hardest part of software development is the software, it's the people. Managing expectations must be done or the project be perceived as a failure.

For example: You are the IT manager of a company, and the CEO says to you: �build me a widget (could be anything), and you have 4 weeks.�, and you follow your software development guidelines that means that the project will take 8 weeks. How do you manage the CEO in this case? What do you sacrifice, the deadline or your software development guidelines?

Neither. You educate the CEO. Read the book (you knew that was coming, right?) and look closely at The List. The List is a prioritized To Do list. It has each feature you are adding, but the features must be broken down into manageable chunks. If you have a feature listed with a one week time estimate, it's too long. Break down features to one or two day tasks. These are (generally speaking) small enough that you can understand the entire scope of the problem which helps you estimate the time more accurately.

This accomplishes two things. First, it makes sure that you have some solid justification for your longer time lines. Second, it provides your CEO with a feature list he can look at and understand. Then he can make an informed choice about the features and timeline. If your CEO doesn't understand why the new features will take two weeks, he probably won't be happy about slipping a timeline. (At some point, you hope he learns to trust you, but that doesn't always happen.)

By publicizing this information you enable your management chain to make informed decisions. Your CEO becomes a participant in your development process, not an adversary who feels like he has to drive you to get more work done. You've created a transparent process in which he understands what you are doing, not a murky bog of "development work" that looks like you are hiding lazyness.

Make sense?
[ August 02, 2005: Message edited by: Jared Richardson ]

[Pat Dennis]

Thanks for the great feedback guys, I look forward to reading your book.

Kind Regards,

Patrick

[Ilja Preuss]

Originally posted by Will Gwaltney:
(contrary to popular opinion, sometimes adding more developers to a project actually does let it ship earlier).

I think the original phrase is that adding more developers ot a *late* project makes it get even later.

[Tony William]

you may be interested in reading the following thread:

Working hours

This is something also related to managing the expectation from our managers. Jared has made a good point there:
Creating a process transparent enough that the manager can ~participate~ not just review and comment