Take the time to define “what does it do, and for whom does it do it?”

I hope you don't mean the hoary old "Plan me harder!" chestnut. isotope and I discussed this the other night, and neither of us can think of a project where completely nailing down requirements before writing code actually made a project succeed.

Contrarily, we could both think of plenty of projects that almost released on schedule and very nearly came in on budget but never satisfied the users despite stubbornly sticking to the jot and tittle of the original specification. That's okay, though, because next time they'll plan harder!

I'm with you on this one. My corp is always saying that we need a complete set of requirements to start the work.

I couldn't disagree more. As soon as you have enough requirements, you should start and then start iterating through solutions. What's "enough"? I'd leave that up to the lead developer.

--
I used to drive a Heisenbergmobile, but every time I looked at the speedometer, I got lost.

My corp is always saying that we need a complete set of requirements to start the work.

If you had a complete set of requirements in detail sufficient to describe the problem to solve in its entirety, you would already have the complete source code to the software.

I don't think that's what sundialsvc4 meant. I think he was talking about "knowing the audience" and knowing the range of the project. You do not need to know how exactly will everything look or work, but you need to know what's the purpose and range. And not try to be everything to everyone. But maybe that's what I would like him to think by that :-)

Jenda


Support Denmark! Defend the free world!

You got it right.

The question of “what does it do” is much more important than “how does it mechanically go about doing it.” Most machinery has a protective cover; so does programming. It is a surprisingly easy thing to buy-or-build a beautiful looking machine that does exactly what its designers intended, but that doesn't do what you need it to do. You get the very-uncomfortable feeling, uncomfortable and also very-correct, that the design team never really understood what was needed. So the machine is tight, beautiful, well-made, and utterly useless.

Another issue can be the unspoken requirements. For example, no matter what my inward- or outward-facing website is supposed to do, I don't want it to be shame-faced by some "133t h4x0r d00d," and I also don't want it to wind up on The Great Grand-Nephew of Web Pages That Suck. I want it to be, as IBM would say, “Reliable, Availabile, Serviceable.” To have “merchantability and fitness to a particular purpose.” That takes a tremendous amount of discipline to achieve as a consistently reliable and predictable process, and most shops don't seem to be able to do it.

Take the time to define “what does it do, and for whom does it do it?”

I think there's more to it than this -- it's an issue of managing expectations. and knowing your audience.

Many programmers aren't willing to roll out without the full functionality, for fear they'll be forever judged by first impressions. (and I admit, I've done it more than a few times) For many larger projects, you need to get some of your intended audience involved early, and have them test incrementally, rather than to tell you that the whole thing sucks 2 weeks (or 2 days) before you're supposed to go live with it. Giving them a chance to interact with the system early and make recommendations can help get their buy-in, and they can champion the project to their peers.

You need to really know what it is that people want from the system, and be realistic about what you can deliver given the resources available. If there's something that people really want, but won't be available 'til version 2.0, let them know, and let them know early -- you don't need them badmouthing they system because it's missing some (seemingly minor) functionality that they really wanted. If there are things they truly need, then you either need to make sure it gets into the first public release, or only roll it out to a subset of the audience that doesn't require that function. (which means it also has to play well without whatever systems already exist, and hopefully, people won't have to keep switching back and forth between the old and new systems)

Programmers need to talk to their users -- they know what they want, normally. They might want stuff that we can't give them, but they can let us know what is critical for their work. If we don't understand what the purpose of our systems are in the larger context of their work, we're doomed to fail.

I would dare to reword and redirect the last paragraph:

Programmers need to be allowed to talk to their users -- they know what they want, normally. The users might want stuff that the programmers can't give them, but the users can best let the programmers know what is critical for their work. If the programmers don't understand what the purpose of their systems are in the larger context of the users' work, we are all doomed to fail. "Send your questions to our project manager, who will tell it to the secretary, that'll mail it using her own words to the secretary of the (whatever level) boss within the client, who'll eventually forward it to someone who may eventually end up using the system being built and whose response wil travel the same way and end up in the developers mailbox within mere two or three days" doesn't cut it. Don't protect the developers from the potential users and the potential users from the developers!

Jenda


Support Denmark! Defend the free world!

Just to reemphasize your rewording and redirection, the delays and paraphrasing that you mention are just the tip of that iceberg. In my experience, lack of direct contact with the actual end users tends to end up with the software being built to do what the end users' manager thinks they need (or, still worse, what the manager thinks they should need), which often has little or no connection to the reality of what the end users will be doing with it.

Design-by-management-proxy also tends to lead to the software being created solely to duplicate the existing process(es), but with newer, flashier technology, while allowing the developers to get in there, talk to the users, and actually gain at least a rudimentary understanding of not only what the end users are/will be doing, but also why will often allow for better processes to be developed.

I know where you're coming from, but I think we're in two slightly different situations here ... you're likely dealing with a case where people are forced to use the project. I've been in that situation, and people complain about what they don't like, but they might not send it to the right people, and might take days for it to reach the developers (if ever).

On my more current work, I'm building software that is completely optional. It's intended to help people, but no one's being forced to use it. When I built the system for Fark -- if people weren't happy, they'd leave ... we had no idea why, and really, we didn't care. (this was well before Drew was selling advertising) The submission queue was just to make it easier on the admin, so we could weed out the crap people were submitting.

Now, I'm working on software to help scientists find data. They have other ways to find their data, so most don't bother using what we have ... if they use it, and aren't instantly happy with it, they don't fill out the feedback forms or e-mail us ... they just go away. So, once or twice a year, I go to conferences to tell people about new features and try to get the scientists to tell me what they want as new features ... some aren't willing to tell you what they're looking for, as it might tip their hand on what sort of research they're trying to get funding for, others are just happy with their current methods and don't care.

...

Of course, in some ways, I've probably harmed the users by taking to them. I tried sending out an explanation of what's wrong with some of the catalogs, and someone asked 'what's "normalized data"'? We speak completely different languages when talking about the same problems, but I can't design an interface for their use without understanding how they think about their problems and the words they use to discuss concepts within their specialty.

But, anyway, I think jenda and I both agree -- developers and the users need to interact, so we can understand what the users want and can fix the problems they find.

Big topic. Why do projects fail? They fail on expectations.

You have the expectations of the intended audience. What do they think they'll get? Often we set them up for failure because we ask them to come up with a pie-in-the-sky laundry list of wants and say "uh yeah, we can do that." And we aren't lying. We can. But they probably won't get it all on first release.

And then there are the expectations of the development crew. How much testing? How much can we count on the QA group? How much can we count on the user group? How much input do we get in how we solve problems?

It's more amazing that large projects work, than that they fail. And it takes a special skill set to pull it all together and keep things going. Your ace number 1 perl guru probably doesn't also have that skill. I'm not saying that the project manager should get paid more than the ace guru, but I am saying that you have to respect that it's a different skill set and it's a pretty darn important one.

Don't “scrap the old and start over.” Don't even say in public that you might.

I think you've chosen a solution without defining the problem here (or at least, you've got a specific solution to a very general problem). There are plenty of times where it's a good idea to scrap everything and start again. This can be from the technical end (e.g. the code base is barely maintainable, the design has fundamental flaws, the infrastructure is no good), or from the customer end (e.g. the system never worked properly, or did what we wanted it to do, the business has moved on, numerous "paradigm shifts" have occured).

I agree, it's not a good idea to scrap everything without a good reason. But good reasons often crop up. And it's important that the "business" type people, who are often the ones who write the cheques, recoginise that this might not be something initiated by them. Just because something "works fine" now, doesn't mean it's economical to leave as is, when every minor change takes weeks to complete.

More generally, I think Agile can offer a lot of help in most of these issues. I prefer Scrum with XP-style development practices. A lot of people still baulk at the mere term "Agile", but a lot of that is because it's been adopted as a buzz word, and completely mis-interpreted. Even if you do understand the theory side, putting it into practice can be a lot harder than you might think, especially in large organisations, with a lot of "baggage" entrenched in both processes, and people's expecatations. (Hint: to put it into place in this sort of environment, you almost *have* to have an independant Agile Coach. You'll probably find that as soon as you start trying to remove impediments, you'll find huge webs of resistance from upper management that are difficult to break down yourself).

I think what people who've put Scrum in to practice well find, is that if they really want to produce working software on a regular basis, they have to address how the entire organisation operates. To me, that's a reflection on the fact that software has become so integral to so many business, and is much more complex than your average (non-development) project.

Bottom line is: getting it right is hard. And we're still learning how to do it.

As a side note, it probably goes without saying, but there is only so much you can learn out of books. Experience is crucial, including learning from others' experience.

My brain generally clicks-off when people drag out sports-analogies for any reason. Programming isn't a sports-event; it's engineering. (Let the record show, furthermore, that “armchair quarterbacks” actually have no idea how a professional sports team, nor the surrounding business-entity, actually works. They drink the beer, maybe pay $34 for the book, and imagine that they do, getting smarter and smarter as the afternoon wears on.)

I'm guessing you're referring to the name "Scrum"? Well, it was actually named by a couple of Japanese guys who clearly didn't understand Rugby, because their analogy doesn't make any sense. But at any rate, it's just a name, and the methodology *is* based on engineering (specifically, lean manufacturing).

I suppose they fancied themselves as marketing gurus. The fact that they originally named the Scrum Master role "Hooker" (a position in Rugby) proves they certainly weren't.

Anyway, I'd strongly recommend you go past the name and at least *look* at Scrum (or other Agile methodolgies). Even if you don't want to use it, you may find parts of it interesting and valuable.

Good design, whether it's for a program or a building, needs to begin with a conceptualization phase, which in turn leads designers to figure out the best way to implement their designs. All too often people want to jump right in and get their hands dirty with some code, but this has a tendency to make more work.

I've found that too much planning can be as bad as not enough, though. Too many people sitting around not actually doing anything for too long saps energy and time. It's always best to begin the design process with a simple overview of what you're trying to achieve, and this is where a good manager is critical, keep everyone focused on that.

Regression Testing?!?! Bite your tongue!! Why would Management want to discover regression issues? "Those are issues that 'Rev. 9 million 5' can fix"..."an undocumented feature"!!! :-D

I agree with apl we must have Regression Tests, you must discover what broke when you changed/added 'XYZ'!!! No excuses for not doing Regression Testing, however Micro$haft ships patches without testing all the time...forcing every IT shop in the country to do their OWN testing before deploying a fix enterprise-wide.

ki6jux

"No trees were harmed in the creation of this node. However, a rather large number of electrons were somewhat inconvenienced."

One doesn't have to dwell on Regression Testing. Management has their priorities even as Programmers do. The difference is, they don't usually tell us why they need to shave time off the estimate. All we see is that we're being forced to ship something which we know is not complete.

But who gets the blame? You'll notice the title of this thread is not Who do so many projects get mismanaged, so often?.

Theory begins by denying reality - to talk about reality, to go around reality, to catch anything that attracts our sense - intellect and abstract it away from reality itself.

Begginning with saying that the outside world is not a fact, that existence can be doubted and that every proposition in which reality of the outside world is affirmed is not an evident proposition but one that needs to be divided, dissected, and analysed.
It is to stand consciously aside and try to square a circle.

Projects fail on expectations and bad criteria. Everyone gets them mixed up and start talking about who's methodoligies are better.

Perhaps, one day, after one has delivered a project where, for example:

That is when one should start discussing achievability, business projections and the stock market.

Like an ancient buddhist monk, you should transcend all your teachings and simply deliver the solution. Everything before it and after if is the journey of your life.