EXPERT RESPONSE
Your question is an extremely interesting one. It is based on an assumption that I want to test before I answer your real question.
So here's the assumption I want to test: consistency in software development life cycles is desirable. It seems clear from your question that you believe there is some intrinsic value in every development group following exactly the same life cycle. I'd like to ask you to think long and hard about that. Why? What specific values does following the same process add to the end product? Is the software better? Is the team more productive? Is it easier to attract and retain good employees? Is your company more competitive because everyone does everything the same way? Do concepts move to products more quickly? Does your stock price go up?
Most of the time, consistency in SDLCs has very little to do with these very important questions. If that's the case, why get uptight about forcing every peg through the same square hole?
Let me give you some reasons why, all of which (in my opinion) are not nearly as important as the questions already listed:
- Projects are easier to audit
- You can use a lot of templates for deliverables
- Status reports all look the same
- Everyone knows how to log defects, requirements, etc, no matter what project they are assigned to
- Managers tend feel more comfortable when they don't have to rely on employees making the right decisions about how to proceed
In my mind, these benefits are not particularly substantial, especially when you consider some of the potential drawbacks of "consistency":
- Using the same hammer for every job results in frustrating inefficiencies for developers who "know there is a better way"
- Employees can stop developing their ability to make good judgment calls
- Your organization can develop an "it doesn't matter if the project fails as long as we follow the process" mentality
- Talented people will not stand for it -- they will ignore inefficient process requirements or leave (or both)
It's not unusual for different development groups to have slightly different software development life cycles. In some cases you will have various development groups that have completely different approaches to developing software. Take my situation, for instance. I work in an IT department where there are at least three different methodologies in place: waterfall model, Rational Unified Process (RUP), and scrum. Further, within these methodologies, various different groups do each one differently. I do scrum with SharePoint, another PM does scrum with Trac, yet another group does RUP fully integrated with the Rational Tools, another does RUP but with only some tools, and so on. I'm convinced this diversity of approaches to software development is healthy for our organization, and I'd challenge you to think twice before you make consistency across all groups one of your top priorities.
If I haven't dissuaded you, if you still believe that consistency will have substantial benefits, that it will make your projects more successful and help your company compete more effectively, then I do have some pointers for you.
Don't rely on documentation to enforce the process
I once worked at a company that spent more than a million dollars with a big consulting company to define a custom SDLC just for them. And what was the result of this six month effort? A big meeting was held where managers and consultants proudly unveiled our SDLC like an artist unveiling a marble statue. The main deliverable was a chart, printed on plotter paper that was at least twenty feet long. We hung it on a wall, and we would stop and look at it admiringly from time to time. Eventually, it ripped and someone threw it away. At twenty feet long, that chart was worth 50,000 dollars per linear foot.
This is an extreme example, but it demonstrates an important point: Documents don't make anything happen. People do. When someone asks you about the SDLC, don't point them to a document. Walk them through it patiently and without condescension. Don't make it "bad" to not understand -- this will alienate you from the development teams and make them less receptive to your coaching.
Focus on the end game
Don't try to sell consistency for its own sake. Instead, talk about the value consistency provides. If you have come to the conclusion that consistency provides value in the ways I described in my first set of questions, then you should already have answers for this. Talk about how it makes you more competitive, how it helps you deliver projects faster or with fewer defects. If you can't explain this, then you should reconsider whether consistency is, in fact, desirable.
Be an asset
One of the best ways to drive adoption of a process is coaching others in the use of it. Get involved with projects and find ways to add value. When they ask for help, give them more than they asked for. Try to think of ways to help them see you as an asset to them, someone that helps their projects be more successful. You don't want them to see you as a project policeman (or policewoman) whose sole concern is whether they have created every required deliverable and doesn't care about the project's outcome. This will set you back millennia.
|
|
 |
Keep it simple
Make your process easy to follow by reducing ceremony (e.g. required "meetings" where approval is granted, like a squire being knighted) and formality (standardized documents requiring signatures). Ceremony and formality should ONLY be used when they are actually needed -- like when obtaining funding to create a new product, or acceptance of a fixed bid deliverable. Don't create non-value adding ceremonies and formalities around interim deliverables like requirements documents, designs, code, etc. without EXTREMELY good reasons, such as avoiding accidentally killing people if the software fails. If your software's failures don't kill people or destabilize economies, you probably don't need to get written signatures on every piece of paper your project generates.
|
