Recently I participated in an interesting discussion about software development projects. There was an underlying assumption by some that using a consistent software development life cycle (SDLC) on all projects is a good thing and someone asked how to best enforce it. For me, enforcement is a morale killer. In working with many companies over the years developing software, some had methodologies and used them with great success, others used them but projects still failed. Some organizations, who did not have any standards, wasted a lot of time starting over for every project and still others without too many standards remained nimble and innovative with break-through and cost saving results. Training teams to make confident choices is more essential than dictating a methodology. I have argued with many quality assurance people when my judgment calls were in violation of a methodology step that did not add value to our efforts. Organizations should concentrate on teaching their employees approaches to handle different types of projects and challenges.
With training and project experience one can balance variables such as risk, cost, complexity, and importance of the project to determine which deliverables and efforts are beneficial. Does that mean you have to create a lot of paper documentation? It really depends on the project. Are lives at stake? If not, less formality and rigor is my preference. My mantra: Only work tasks that add value. Beware that most SDLCs are written for complex projects. If your effort is small in scope, has clear requirements, and minor business impact you do not need tons of documentation. Requirements may be confirmed informally. These are important considerations for a business analyst when planning.
I recommend organizations adapt a small number of easy- to-use development life cycles, provide people training and make the lifecycle options visible and available. I appreciate the overall structure, templates and reference that most development lifecycles provide to a project team, especially as a communication tool. Trained teams can benefit and develop efficiencies by having standards that work for different types of projects. Talented, experienced people can be creative and use good judgment to tailor the SDLC to what is important on their projects.
In other words, I know what I like to eat but it is also nice to select from the menu of my favorite restaurant. I can make my choices more easily, request menu adaptations as needed, and get to the fun part faster which is enjoying a good meal. Using software lifecycles for guidance, consistency and flexibility, need not constrain, delay, or negatively impact the project results or the team. They just let us get to our dinner faster and so we can enjoy the meal. I would love to hear your stories about methodology implementations at your organization.
May 7th, 2008 at 5:01 am
From my experience, normally the user is the party who keep chasing after documentations. They treat documentation as important as the system and must be ready before the system ready. Documents like system and functional specs, design details, data dictionary, user guide, deployment guide etc are used by them to safe guard their job, where any discrepancy between the system and business needs, those documents are the judges. In fact these documents are important for the development team too as proof of requirements sign off.
May 7th, 2008 at 1:39 pm
Andrew - I agree that many business stakeholders are interested in documentation One reason is because they need to explain or train the impact of systems changes to the rest of their organizations. I would like to think that no one creates documentation for job security. I think you are referring to the deliverable sign-offs (as job security) which is more of an IT project management effort to protect themselves if the business says they are unhappy with the resulting software system. They can say your sign-off was on the detailed documents, and the software is built per specs. Although that may be true (and binding) - does that lead to a happy, satisfied customer? Is the project deemed successful in that case? I would say no. By the way the BA has failed in communicating clearly with the stakeholders. I think that is why agile development began with a focus on producing less documentation- "only what is necessary". Agile thought leaders say that there has been too much focus on documents and not enough on whether the customer getting the software that they need. I absolutely agree that we should only produce documentation that adds value.