Top Ten Requirements for Your CM and ALM Strategy

[article]

In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.

Summary:
Joe Farah takes an in-depth look at the top ten requirements needed for a successful next-generation configuration management and application lifecycle management solution strategy.

In my article, "Building a CM and ALM Strategy," I took a high-level look at the requirements needed for a successful next-generation configuration management (CM) and application lifecycle management (ALM) solution strategy. In this article, I’m taking those same requirements and looking deeper into them.

1.  Low Total Cost of Ownership (TCO): Obviously, open source; it's free—well, except for the training. OK, upgrades too. Some administration, but that's to be expected. And we'll worry about the rest of the team later—when we buy more tools—hopefully they will integrate nicely without too much effort. The tool has all sorts of ways to customize it; all we have to do is provide the staff. Oh, and I'm sure there are some open source user interfaces that can go on top of the command line.

Get the picture? Open source may very well mean free, but it doesn't mean low cost. Yes, it is preferable to spending several thousand dollars licensing per user for a commercial solution, especially one that's even got higher training, consulting, and administrative costs. So it certainly looks a lot better. The problem is, you haven't looked enough.

What about a tool that costs a few hundred dollars per user, requires minimal training, has virtually no administration, and does not require a bunch of add-on tools or a separate database product in order to complete the solution?  Have you found one yet? Look harder.

2. The Best Technology: Get smart! Don't use vendors to show you how their solution is best. Do some homework and pick out the best features of various solutions. Then bring the vendors in and ask how they support these features. We're talking CM and ALM features; the requirements are well known. If vendors can't meet the feature requirements, cross them off your list—DON'T LOWER YOUR REQUIREMENTS.  Use the vendors to learn all the best features and then look for a tool that provides all of these features. Realistically, you may not find 100 percent coverage in one tool, but if you look hard enough, you will come very, very close.

3. A Team Tool: Developers don't like overhead. They want a tool that has little overhead or one that they are familiar with. The same goes for the rest of the team: testers, project managers, CM managers, development managers, executives, technical writers, marketing team, and product management. Don't provide each group its own tool—you'll NEVER get them to work together. 

First of all, raise the bar. Don't get a tool that minimizes developer overhead. Get one that gives them a lot more than they could have hoped for and that makes them more productive. Give them something that does things for them that they'll go "wow" at; things that they haven't considered. Developers are familiar with low-level CM tools for the most part. Show them a way to navigate the riches of the CM repository to help them do their work more productively. Don't minimize their interaction with the information.

Then move on to each and every role on the team. If you could have the best tool for a given role, what would it do? What would make it be so easy to use that training is minimal? How does it increase the user’s knowledge in his role so that others consider him an expert?

This is the type of team tool you need.

4. Product Quality and Product Requirements: These sort of go hand in hand, as they focus on the customer. Agile works well in many scenarios, but whatever the scenario, clear communication of requirements, including the fact that a customer seldom knows exactly what he wants, and the ability to change requirements incrementally is important. Maybe in a launch vehicle the requirements change less, but change is still inevitable and the better it's supported, the happier your customer will be.

Yes, it's important to trace test cases to requirements and do functional audits, etc. Good tools can do these. But great tools go beyond and answer questions such as: When did this requirement last fail to be met? What requirements have changed between these two builds? What's the status of each customer issue? What's the status of each customer?

Great design can result in a great product. But take away the proper ALM functions, and your great design will not result in a successful product. Delivery issues, customer feedback, quality assurance issues—these will all haunt you if they are not dealt will properly.

Pages

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!