Saturday, April 21, 2007

What your project success is driven by?

What would be your answer to the above question? Use-Case driven, Test-Driven, Scenario-Driven, or perhaps Feature-Driven.
People often talk about these drivers as the only forces steering projects and shaping project plans. But in fact these mechanisms are used for defining and managing projects’ scopes. I believe without Iterative and Incremental Development (IID) approach you won’t have the means to implement a practical solution that users and stakeholders can take advantage of. My main reason is latent in the definition of Stakeholder and Stakeholders’ role in the success of a project.Stakeholder in “Use Case Modeling” book of Kurt Bittner and Ian Spence is defined as an individual who is materially affected by the outcome of the system or project(s) producing the system. Hence, one could draw the conclusion that the best impetus for developing a system is its stakeholders’ feedback and their acceptance of the solution.They are the primary source of requirements, constraints, and risks for the project. They supply the funding and audience for the project and will make the decision whether the project is worthwhile.In my opinion, IID is the right approach to get stakeholders involved. You need to get their approval at the end of each iteration to be able to move to the next one. That empowers you to revise your plan and improve your development process.You can also embrace change requests – which the risks they impose increase as you get closer to the end of the project - from the outset of the project.
Utilizing IID you can suppress “Change Prevention Process” anti-pattern the goal of which is to prevent new requirement being added to the project or existing requirement expanded upon. Another word, sticking to the original plan and requirements and using it as an excuse to stop users from changing them. I would say that's a common issue in all projects avoiding IID. Of course, in order to avoid falling into "Never Ending Change Requests" pitfall all fundamental changes need to be detected and addressed before architecture is solidified.

To summarize, your project has to be Stakeholder Driven.

2 comments:

Anonymous said...

Hi Amir,

How's it going?
It's been a while that I haven't dropped by.
I can see you've turned your attention to more architectural stuff and I can see a comment from Scott Ambler in your last post. Isn't he the famous agile guy? That's cool!
Regarding this particular post I gotta tell you, it really got my attention. As an ex-IT guy and an IT user I absolutely agree with you. Nothing really make me happy but a system that really do something for me and make my job easier and I hate nothing more than a product that make my life miserable.
I'll try to keep my eye on your weblog. It's getting more interesting, you know?

Jim

Unknown said...

Hi Jim,

How'ya doing? Yea, It's been a while. I'm glad you liked the writing. I'll try to keep this up.
But sometimes I get this feeling that I have to write about technologies as well.
Anyway, thanks for the comment.
Don't be a stranger.