Developing Waterfalls
How to Effectively Drown Your Software Schedules
-- Jonathan Ng
Last month, I shared with you two pet peeves of mine and some of my software
engineering experiences. Well, if your river raft hasn't already split in two after those
rapids, I'd like to share yet another experience - one that I'm sure many of you can
relate to. Okay, let's have a show of hands - how many of you out there have had been in a
project where your manager thought only about the bottom line?
I see a few heads nodding. Let me tell you about my experience, and to prove to you why
this type of management doesn't work.
As a coop, we are often required to do many projects. Sometimes these are meaningful
projects, sometimes they are less than meaningful. However, this one I'm about to discuss
was perhaps the most meaningfully meaningless of all projects. I was to develop a skills
database along with 3 other coops for the company. It sounded simple enough - it was a
relational database that is supposed to relate skills with employees. We were a consulting
company after all, and it would be nice if our managers had a tool that would help them to
decide who was qualified to go to which project.
We set out to do a requirements analysis to determine what was needed. Upon
interviewing our first candidate, we were confronted with the expression
"Again?". Well, we thought it was rather odd, but apparently, this project had
been attempted over 6 times in our regional office alone! Each of those 6 times it had
failed. So, we thought - bad luck but hey, we can do it this time right? Not a chance. You
see, it was neither the people nor the developers that was the problem - it was the
management. Let me explain.
Two weeks into requirements analysis, we received an email from our project mentor
about a particular upper manager who wanted to see us. He was wondering why there were
four people allocated to this "little" project (that in his mind would take
"only 2 weeks to complete"). Now it was of particular interest how this manager
convened the meeting - he walked over to our cubicle area to within about 2 metres of
where all four of us were working. He then proceeded to whisper in the ear of our project
mentor about this meeting, who then emailed us! I know he's an upper manager and we were
just measly coops, but hello! - we were only 2 metres away!
We had the meeting, and presented a preliminary requirements analysis. We had taken the
majority of users of the system, separated the requirements into "must haves",
"nice to haves" and "wishful thinking" categories. As we presented
this to a board of managers, we were interrupted by a question from the upper manager:
"How long do you estimate for the project?". What he was really saying was,
"Do you know how much this is going to cost me?" Now, as usual, I refuse to give
estimates when I have not even completed a full requirements analysis... which is exactly
what I told him. I said, right now it would be foolish to give you an estimate because
it's liable to be wrong anyway. Instead, let us finish the requirements analysis (another
week) and we will have a much better idea for you.
Didn't work. He started touting numbers. He jumped up and said, "Did you know you
guys are costing the company $80,000 for two months?" We were flabbergasted. Where
did that figure come from? Turns out this figure was our opportunity cost. It was an
internal project. Why were they calculating us on opportunity cost? It is true we were a
consulting company - but the funny thing was that we were "on the bench" (i.e.
had no work) for the past 3 weeks already, and the company wasn't expecting any short term
opportunities. In other words, if we weren't on the skills database project, we would be
doing nothing! The "bottom-line" argument simply didn't make sense. It got
worse.
We proceeded with the rest of the interviews, one of which was the manager himself. It
was a thoroughly unpleasant experience. Instead of answering our questions, he told us
firmly that he wanted the database to be the way he wanted, nothing more. The only problem
was that he actually wasn't the primary user of the database.
At this point, we knew exactly why this project had been attempted 6 times. Each time,
the user requirements were never satisfied! And thus, the resulting systems were never
used. Well, we had no choice either, so we took the manager-inspired requirements, and we
came up with an estimate: a little over 2.5 months + 1 month - .5 months. Since we had
only 2 months left in our term in the best case, we could finish it on time. In the worse
case, we'd have only a design done. We thought that maybe we can convince him of that -
produce an extremely well documented design and have him hire the next coop to complete
it.
I decided that this time, we weren't going to let him get away with intimidating us
with the bottom line. We knew he would be picky about the estimate, so we performed an
estimation in 4 different and independent ways - to prove to him, that yes, it really is
going to cost this much - even with a reduced set of requirements. We did the following:
- Estimation by seat of pants (in other words, a wild guess)
- Estimation by parts
- Estimation by function point analysis
- Estimation by asking an expert from within the company.
Amazingly, all four estimates produced results within the same vicinity. We had another
meeting with the manager to present the estimates. This time we were prepared.
In the end, the project was cancelled. It was a wise move, because the system that
would have been implemented would not have met user requirements, and thus would not have
been used. Nonetheless, we as a team felt awful because we had so much wanted to finally
implement a correct system for them, but instead we were asked to do a system that didn't
match any of the user requirements and still had to take 2.5 months to complete.
So my message to managers is this: wake up! The high-tech business world is no longer
going to put up with old-school managers. In today's world, if your company is to be
competitive, and especially if you care about the bottom line, your business has to be
flat, and you, as managers, are going to need to know more than just business management
skills. An ideal manager has to be someone who not only understands the CEO and the
financial books, but one that understands even the lowliest of jobs under his/her
management. That's where the skill is. Don't patronise them, and especially don't discount
their job or their knowledge. You hired them to play that role in the company, didn't you?
It's not everyday that someone will go to the extent that I did in my project to prove
my point. But in a way, as technical computing science people, we often tend to be a
little too lenient on the unrealistic expectations of our managers. Rapid development is a
tricky business. As I mentioned last month, it has to be done right. Doing it right
involves the whole team ...and yes, that means management too. Ultimately, it pays off. If
you pay attention to the little things that may seem to deviate from the bottom line in
the short run, you'll experience a team dedicated to working for the company and the
product, and you'll experience record growth. Skimp on the little things and you'll save
in the short run, but your bottom line will remain exactly that - down at the bottom.
P.S. I've been asked to think of a name for this column. And you know what? I'm stuck.
So I'm going to ask you. If you can think of a good name for this column - an editorial
column on software engineering practices, please email me with subject line "Column
Name": ngt@canada.com; If I like a name, I'll use
it and mention you in my next column!
|
