More on Successful Projects: LeanWings, GR Testers, Part 2

A few weeks ago, in this blog post, I described the discussion from a LeanCoffee format meeting of GR Testers on what makes a successful software project.  What I did not describe are those topics that did not garner enough votes to be discussed, or those which we ran out of time to discuss that evening.

I find these topics interesting and perhaps a bit revealing.  What would have been discussed on these factors contributing to the success of a project?  I suspect that in the course of conversation some would have questioned the assertion that some of these would actually contribute to the success of a project.

The question of what makes a project a success is an interesting one.  We have all heard some level of discussion around this.  I thought the ideas expressed in the meeting were quite good, for the most part.  Honest Communication was a core theme that seemed to bubble up even in the midst of discussing other ideas.

And so, what did not make the discussion?

In no particular order:

A project is a success whenever a major stakeholder says it is;
OK, well, this basic idea came up in a couple of ways and a couple of different perspectives.  Does this really contribute to a success?  Is it part of a greater measure?  I'm not sure. 

Setting Expectations;
Isn't this part of the open communication?  You know, people say what they want and others say what they can provide and people keep talking until they reach an agreement.  Then they need to remind themselves and each other what they agreed an committed to.


Communication with end users involved;
The is tied up with the expectations thing, right?  Unless the "end users" are not actually employees of the company.  There are other ways, of course, for example contacting a user group or some other affiliation of folks who
Check doesn't bounce;

Trust;
This is an interesting one.  Trust is nearly impossible to achieve in an environment where folks view others, other groups, teams, business experts, developers, testers, PMs, with suspicion.  The idea of "what are they up to?" will undermine the chances of trust growing and blooming.  When the atmosphere is confrontational, there is almost no chance of trust developing.  Honest communication and delivering difficult messages, without drama and without guile can help build trust.  Having said that, "Trust" can contribute to a project's success.  However, it is often reflected in other things.

Happy with Outcome/Code/Performance;
Isn't our goal to make sure people are happy with the outcome?  The great question is "Which People?"  Hmmmm. This is certainly a consideration - after all, if no one is happy with the results, by some measure, is there any chance of the project being called a success?  Probably not.

Corporate culture;
OK - See Trust and Stakeholders and a bunch of other ideas.  I can see how the culture of the organization can help make it easier for projects to succeed or make it nearly impossible.  I've said before that if people are trying to reign in chaos, that is not going to happen if a big-enough boss does not publicly, consistently support them. Then again, maybe people like that.

It works - all planned functionality functions;
I smiled at this one.  "It works, by some model."  That was what I first thought on this.  Then again, it is entirely possible that delivering all the planned functionality is adequate.  I then wonder whose definition of functionality counted.  What does "function" mean? Who decides what functionality gets planned?  Who decides?  If the one piece a given department really needs does not make the "planned" list, will they agree that the project was a success?

Project meeting/exceeding customer expectations;
The results of the project meeting or exceeding customer expectations is certainly a consideration around the success of the project.  Does this have a true bearing on making a project a success?  Not sure.

Team members only on this project;
This can really help.  Of similar importance is if people rely on each other.  This also touches on many of the ideas that were discussed in the LeanWings session.  Of course, this is seriously tied to the corporate culture thing.  If the rest of the organization isn't on board, then this one probably isn't going to happen, right?

Collaboration;
That ties to the one above.  It also ties to the question of corporate culture and a pile of the items discussed in the meeting.  Real collaboration doesn't happen without open, honest communication.  For that you kind of need trust, right?

Establishing KPI and reviewing them after project completion;
Ya know, 20 years ago I might have been all over this in agreement.  Now, part of me kinda wishes this one had made the cut to see what was meant.  Do KPI's really ensure success?  Or are they something else entirely?

P1 issues addressed prior to prod deployment;
P1?  As in Priority 1?  As in "no show stoppers"?  As in "all the really huge big problems we found were fixed"?  Isn't this part of making sure stuff behaves?  Again, I'm not convinced this is part of making a successful project.

Requirements met and meeting business users and owners expectations;
Now, some folks may say "Yeah, that makes a successful project, right?"  Well, maybe.  But how ones does that is really the question.

No hot fixes or major issues after deployment;
OK, so this kind of ties into the P1 Issues thing, right?  Stuff goes into production and it works, right?  Or maybe, it works by some measure. Or maybe things don't break.  Or, something.  Right?

===