I have been a software process practitioner for a greater part of my professional life. I have managed projects that are very large in scope, change and complexity. I have tried all approaches, Scrum, XP, Agile, Classic, Prince2. With every approach comes benefits and pitfalls. Still I find all these approaches are too vague for most development teams.

When we are in school, we are told how to do something and we simply follow and get it done. However in software development most often, there is no one to tell what to do and how to do anything. If your project managers are well versed, the developers aren’t and if developers do have some knowledge of software processes, the management is already running late with project.

How to find the right balance?

Additionally, with any process, the two biggest challenges are 1) To correctly document the requirements that all stakeholders and programmers can understand. 2) To validate their understand if they actually understood what we think they understood.

Then there is a third one, TIME.

As time goes by these understandings become vague. Customer thinks that what they said is completely clear. Programmers think it should be obvious how to do something in software to customers. There is no clear language or guidelines on how to visually document requirements and user specifications that can be re-interpreted in the same way all the time.

Then there is the problem of remembering what is requirement number RQ012539023. Did I mention that requirements change…

I am currently fighting with several methodologies to define a clear cut structure to requirements analysis. Hope it gives me something I can use.