The findings came from NICTA’s study of 400 projects shows
and the surprises goes on.
What I am eager to know is,
Defining success is subjective.
Schedules or UML diagrams are just by-products of software development. They are not the software itself. If the resulting software satisfies customer needs, it really does not matter what by-products were required to get there.
"Process" is there to act as an armor. It will protect you from some things but at the same time it makes you more cumbersome. You need to balance between predictability and flexibility.
It is people not process that gets software done.
Well... regarding projects that had no schedule - they should be successful, since if you're given as much time as you need, most programming projects become rather trivial. Removing the pressure of deadlines is likely to result in more intelligent and less pressured coding.
I also saw some research that said that the choice of methodology doesn't matter, but that simply have a methodology helped a lot.
I think we expect UML, schedules and a lot of planning to help with our programming projects because that is what the project management people tell us. This is likely born out of a modernism-inspired need to control everything. But in the end it makes much more sense to just get the coding done and stop worrying about which type of line goes where.
No big shock sadly, call me Ayn Rand but I've long held the view that 1% of the world is driving the other 99% forward.
How is it so? Well, all I see when I read the article is: people are terrible at managing anything but it all works out in the end because it has to. It's really just documented evidence that people are very bad at assessing risk and the best project management is that which accepts and prepares for failures. Any other view is delusional.
If one chooses to define success as getting the project out of the door (and that's not even the worst definition I've heard) then it's very easy for management to claim (or believe) that all is well in the world. The economic pressure after all is just to get the money in the bank, only the very small and very large companies have any invested interest in actually making things work [better].
Why do you need schedules etc? Well so you can combat the risks and make for an efficient company. YOu can get by without any of this (there's no justice in the world) but you increase the risk of massive failure, and in the long run that's going to kill you.
33% of projects said they had no risks, but 62% of those failed
Says everything really. Humans, eh?
How is it so?
It's all a matter of how you define success. I'll define success as "The stakeholders happy with the results."
Typically the way your stakeholders measure the results are along the lines of:
Re: Finding #1) Having no schedule knocks out #2 and probably also #3 (because resource time has a cost too). No schedule = unlimited budget (until someone control of the purse strings figures out what is going on). If your project comes to an end, and the users got what they needed, then it's a success. But by that same measurement criteria, Duke Nukem Forever was a success right up until May 8, 2009
Also, those in charge are often afraid to admit that a project was a failure or even a only a partial-success because it might reflect badly on them and their future career. therefore, even if it's 500% over budget and 3 years late. They always define it as a success.
Re: Finding #2) The most important thing is that you have a plan. The methodology is just a common language within your organisation. UML (Unified Modeling Language) is really just a collection of tools for expressing your plan. It doesn't matter if you are using SCRUM, XP, or just POW (Plain Old Waterfall), you still have to do planning, it just changes when and how often you are doing the planing. If you've got no schedule to worry about, the planning (or non planning) can happen on the fly; and rework because of a lack of plans doesn't matter.
Re: Finding #3) I find that a specious statement; because I know it to be not true. I've seen developers involved in the estimates with all manner of requirements (both in and out of the USA). What you are probably seeing here is segmentation of roles. "We can't send that geek Charley to go and meet with the client, send Bill the B.A. to gather the requirements. He can't do Fizz-Buzz, but he's got a three piece suit."
At the same time, there is a philosophy that some mangers have of giving impossible deadlines to improve performance; and the fear that if we let the workers tell them how long something is really going to take that they will automatically inflate the estimates unreasonably. They believe that Parkinson's Law applies everywhere. This is false as it was only intended to apply to bureaucracies (like government, and administration in a large corporation) and has never actually been scientifically tested. It continues to be perpetuated because it's funny, not because it's been shown to be true.
Why you need schedules, UML, ..etc.
Unless you are in a miracle project, where you have no time and budget limitations, then yes: you need a schedule, you need requirements, you need a plan, etc.
And even if you are on one of these miracle projects, you still risk that someone higher up will wise up and shut you down.
So, they describe the definition of a successful project at the end of the article:
Verner also asked developers what their criteria were for project success. They said:
* They had a sense they had delivered a quality product * They had a sense of achievement * They had enough independence to work creatively * The requirements were met and the system worked as intended
Nothing about delivering on time or satisfying the customer. Gotcha.
I once worked with a guy who defined success as, "Do I get paid?" He was paid for 100% of his projects, failure or not, so he regarded that as a 100% success rate.
Like others have said, success is subjective.
Things like UML and project management only work when the project's ecosystem supports them. If you try to shove PM concepts down a small team's throat, you can cause them to fail, for example.
There are likely to be a number of factors but it comes as no surprise to me that unstructured projects can succeed (and by that I mean complete and deliver the desired benefit to the business, not just shipped something or got to the point the client was invoiced).
Factors that I'd imagine you'd find common to these successful projects would be (one or more of):
1) relatively small size (teams of at most maybe 10 people for no more than 12 months)
2) established and/or bonded team
3) project members with good experience in the business / technology areas in question
4) smart, motivated people involved
5) realistic expectations from management and clients
All these things can exist without solid planning, use of UML or a solid methodology and IMHO will make a far greater difference. I'd suggest that any developer who has worked in a chaotic but supportive environment will likely be able to come up with more postive stories than those who've worked in structured but political workplaces.
And certainly if you look at Steve McConnell's list of top 12 project mistakes, that is reasons why IT projects fail (http://www.stevemcconnell.com/ieeesoftware/bp05.htm - not scientific but certainly things which will ring true for most developers), only one or two of them really relate to process. UML and better schedules aren't going to improve the working environment, sort out employee problems, deal with the politics and unrealistic demands and so on.
So why can projects succeed without these things - because they're important but they're not the most important factors.
if thats true, someone should tell the PRINCE2 guys to pack it in
PRINCE2 was created as a result of research showing that most projects fail (failure being based on: 1) not on time, 2) not to budget, 3) not to spec
on a side note, i dont use UML and get by. mainly because UML cant be shared with clients and not all programmers know it. user stories dont have that problem
--LM