developer.* Blogs - Open Discussion: "Success/Failure Criteria: Some Surprises," by Robert L. Glass - Comments

My personal experience is

Guest — Fri, 01 Sep 2006 08:03:04 -0700

My personal experience is similar or even simpler.

The key factors are:

1. The problem solving environment

- Hej, Tony I have problems with the Tixxxx certificate.
- OK, sit down I will see if I can help.

2. Quick decision process at the company.

- Hej boss, it seems that we need another Test server for this Fixxxx project. Here are the specifications.
- OK, I talk to the big boss that you come in to the management meeting this afternoon to inform them about the problem. By tomorrow I will tell you if we get the money for that. If not we will find out some solution.

That is it. Deadline helps. But those detailed schedules, timesheets, task lists, weekly reports? According to my several years of experience, they do not help at all. They are just constant headache for those guys who want to deliver product. They are just milestones toward to an environment, where tasks are just thrown among departments, and nobody wants to make decisions.

Deadlines and requirements

chrishmorris — Sun, 27 Aug 2006 23:10:31 -0700

Yes PM, I had the same question. I'm also amused by projects which have no written requirements, and still manage to deliver late.

Some projects have a natural deadline, e.g. a tax calculator must be ready for the end of the financial year. I have never worked on one like that. When I've been given a "deadline", it has been a stretch goal, not based on a well-founded estimate of effort.

Usually the true situation behind a "deadline" is that the requirements are fixed, and the project will in fact continue until they are complete. And the developers usually know this.

Some projects have a time box: we'll deliver as much as we can, to the appropriate quality standard, by the end date, then we'll move on.

With incremental delivery, the payoff for each increment is likely to decrease. The agile ideal is that at every iteration, an assessment is made about whether there is a business justification for continuing development. But I don't know how you write a contract that gives a decent level of security of employment in an environment like that.

The worst case is that end date, resources, and scope are decided in advance, without the participation of the developers. Then failure to meet one of the goals is more or less guaranteed.

If this happens, it may not only be the fault of management. It may be their experience that the developers cannot make useful estimates of effort. I suspect that the result in the report reflects this sort of environment.

No Schedule = Less Pressure = Fewer Compromises

Daniel Read — Fri, 18 Aug 2006 06:22:14 -0700

:-) What I took that to mean was the success was defined as the delivery of the desired functionality, but that the project was not burdened (my word) with a schedule. In other words, the lack of a schedule (which I think of implicitly as an imposed schedule), contributed to the project's success. If you take away time pressures, perhaps you take away pressure.

It also occurs to me that the definition of "schedule" used by the researcher could be important to this discusson. Is schedule in this usage synomous with "deadline," or does it mean "a time-oriented plan with a task breakdown and milestones in a spreadsheet or project management software"?

Dan

Most projects that had no schedule

PM — Fri, 18 Aug 2006 01:33:46 -0700

The article stated this as the first surprise:
"Most projects that had no schedule were successful"
I was just wondering: When do you call a project without schedule a failure?

Excellent Point, Chris

Andy Tegethoff — Fri, 28 Jul 2006 06:33:28 -0700

It's this: even in iterative development, there is a lot to be gained from writing the requirements down. The final requirements document will be ready only shortly before the final delivery of software, but in my opinion it's still very useful.

I feel very similarly -- that you only know the requirements once the product moves into production. Requirements documents should be the most "living" of any development artifacts. They are most closely related to user documentation/help -- they have to change through the maintenance life of the code.

Deliver requirements document at end of project

chrishmorris — Fri, 28 Jul 2006 01:31:33 -0700

I'm really with you on this, Rob. Our requirements can only be developed iteration by iteration, hand it hand with delivering the functionality. I'd like to add one point. Maybe you agree with it, and didn't make it explicit, or maybe you don't agree.

I don't mean a huge document. But the help page should be written before the unit of functionality it documents. The project glossary should grow week by week. There should be a list of use cases or user stories, indicating what has been developed, and what is in forthcoming iterations. And a list of high level goals, including those that are yet to be detailed into use cases.

It seems to me that these requirements are in themselves a reusable product. I've often been told to re-implement a programme on a new platform, "just like it was before". In this situation, you don't know which parts of its behaviour are requirements and which are accidental properties. This leads to tension and wasted effort.

Modest requirements documents are also needed to guide testing. For anything inbetween unit testing and user acceptance testing, the testers need some understanding of what the software should do. This understanding should be explicit, not implicit.

I wish I could say that this requirements documentation focuses the discussion with users. That isn't in fact how my current project is going.

Not Alone

Daniel Read — Thu, 27 Jul 2006 15:48:11 -0700

Rob writes: "It's good to know we're not the only ones."

I agree. That's what really struck me about the results of this study, and why I asked Bob Glass to allow me to re-publish it from his newsletter. As one reads a lot of the "how to develop software better" literature, one hears a lot about how it's *supposed* to be done. But many of us could probably think of some example projects that succeeded despite not having been done that way. And we might experience some anxiety around the fact that our project might not be proceeding the way it's described in the books.

This is why I'm skeptical of claims of "It has to be done *this* way or you're doing it wrong!" For example, with all due respect to the many reasonable Agile advocates out there, I've been on my share of waterfall projects that worked out pretty well.

I'm glad this article generated some good discussion. Thanks for the comments.

Dan

Requirements

Rob MacGrogan — Thu, 27 Jul 2006 15:10:47 -0700

What I found most interesting in this short article was the idea that requirements are needed, but not necessarily up front. I actually think it's impossible to have fully detailed requirements (as detailed as they have to be for developers to complete all of their work) up front. Many details are always missed in the initial requirements gathering phase. And as things shape out in the development phase, in my experience, you always end up finding that many of your requirements were wrong or sometimes impossible.

It is very difficult to get your head around everything a software application is going to do before you actually see it do anything. This is why prototyping and itterative development are so useful. Users and stakeholders can't really imagine what they want until they start to see what they're going to get. And they absolutely never think of everything. (Case in point--Business user: We need a screen showing all of today's orders. Developer: Define "today".)

Developers often have to fill in requirements holes with best guesses, or resolve conflicts in requirements that were not obvious until the developer actually tried to develop.

In the project I'm currently working on, we're typically resolving requirements issues up to just a few days before a release/code freeze. It's good to know we're not the only ones.

A Good Project Manager

Rob MacGrogan — Thu, 27 Jul 2006 15:01:43 -0700

The project I'm working on has an excellent project manager. He actually works for our client, but our project is part of a larger project involving both people at my company and also many many more people at the client company.

His role seems to be mainly to be focused on managing project scope and scheduling, at a high level. But day to day, he seems mostly to be fostering communication--bringing the different sub-groups on the project together and sorting out which issue goes to who and so on. He's the guy I turn to when I need something to happen but don't know who needs to do it. To me, that function alone is invaluable because it saves me from wasting time. And since he's high up in the food chain, when someone gets an email from me with him copied and with me mentioning that he needs such and such done, well, action is generally taken right away.

So, Chris H, I would say that my PM is doing exactly what you said a good project manager should. That doesn't mean all of them behave this way, but I'm glad he's there.

What is a "project manager"?

chrishmorris — Sun, 16 Jul 2006 02:44:02 -0700

I'm interested in the report that "In one-third of the projects, the project manager had no say in schedule/budget targets". What exactly were these PMs doing?

I once worked in a wafer fab, making silicon chips. There was a supervisor there who said that his job would be exactly the same if we made fish and chips (french fries in US English). This is the British tradition of content-free management.

I've met programmers from larger companies who have technical leadership and line management from one source, programme management from higher up, and a "project manager" who is following a "project management methodology" without engaging with the actual work. These PMs seem to be universally despised. They are the fall guys, and they respond by covering their butts rather than solving problems.

A real PM must recognised as a senior member of the project's management team, who enables risk management and stakeholder management by the project's managers and developers collectively.

The main role of a PM is to ensure that all the feedback loops are closed. If the relevant information is available to everyone in the project, then usually they will do the right thing. The second role is if they don't, to help everyone figure out why not. It means grappling with the specifics of the project.

I suspect that this difference underlies some of the results of this survey.

Open Discussion: "Success/Failure Criteria: Some Surprises," by Robert L. Glass

Daniel Read — Tue, 04 Jul 2006 12:20:12 -0700

This page is an open comments and discussion thread for the developer.* article "Success/Failure Criteria: Some Surprises," by Robert L. Glass. The article contains some fascinating findings from a survey of 400 projects and what contributed to their success or failure. Feel free to make a comment or start or join a line of discussion.