|
The software developer wants us to wait til he or she is closer to baselining - and is bereft of the ability to tell us, in advance, when he's "there." The hardware developer wants us to wait til the next higher assembly, as he views "the system" differently from our "subsystem" definition and description. The systems engineer has yet another view of "the system," and he is impatient not to lose forward momentum on his progress and his schedule. The customer wants insight, and he's looking to everyone to cooperate in the creation of his view into the progress - but he doesn't want to pay for "too much control" to ensure that a satisfactory assessment is possible, for us to present to him. The program manager berates us for over managing the system components for him - oblivious to the fact that the version control he agreed to and endorsed during the early days (you know, the first few meetings when everyone was smiling and singing "We are the World," or "Kumbahyah?") when we all set out to create a successful outcome. Even our peers disagree with us - everyone has a different view of the version control process, its need, and its benefits and drawbacks. So what's the answer to this dilemma? Part of it is education - teaching all of the vested parties in the program how, exactly, version control will be applied, and what the outcome is going to be, for them and for the program. Part of it is persistance - establishing your plan, working your plan, and making sure that it's a success. Part of the answer is consensus - teamwork to ensure a good outcome as the process grinds its way to completion. Part of the success paradigm is consistency - applying the rules the same way, each time, or at least providing an understanding to those who are participants into your approach. Then, documenting your method, your process, and your results to all parties furnishes them with a record of events and the outcomes created as a result of the process. Finally, communicating - a recap, update, and metrics development and application to portray changes, evolutions, baselining frequencies, capabilities that describe each baseline - demonstrating the process and the benefits all show the value of version control. What's your definition of version control, and how can you contribute to a better understanding for all of the involved parties, and a more satisfactory outcome for the project? I'd like to see a start to finish plan for completing the steps above - and your strategies for making them a reality! Cynthia C. Hauer is the Chief Executive Officer of Millennium Data Management, in Huntsville, Alabama. She has 21 years of experience in Information Technology which includes extensive involvement in CM, DM, data base design, user interface, data storage, CALS and all facets of system design and implementation. Ms Hauer holds a Bachelor of Science in Computer Science and is certified as CMIIC and CCDM, certifications in both ICM/CMII and NDIA, respectively. Cynthia is an occasional contributing editor for the CM Journal and writes a regular "rant" for the CM Basics newsletter. You can reach Ms. Hauer by email at chauer@cmcrossroads.com.
Set as favorite
Bookmark
Email this
Hits: 5324 Trackback(0)Comments (0)
|
| Last Updated on Tuesday, 24 January 2006 03:26 |
TrackBack URI for this entry
Subscribe to this comment's feed