More white papers:
Find out more ...
|
|
Neuma White Paper:
CM: THE NEXT GENERATION of SCM for Small Business
It used
to be that SCM was a complex and effort intensive process that small projects
and businesses could not affort to invest in.
Tools were expensive, automation was a daunting task, and the imposition
of process on the small development team would take away the small business
advantage of moving quickly. Today, and
certainly in the next generation of CM, quite the opposite is true. How can that be?
The
introduction of SCM into a project involves:
Identifying a CM/ALM process to be followed
- Acquistion
of tools to support CM/ALM
Customization of the tools to support the process
Training of personnel on the CM/ALM tools and process
Training CM managers and administrators to support the process
Sufficient quality management to ensure the process is being followed and is
beneficial
Are these
steps different today than they used to be?
Not really. The steps are the
same, but the cost and effort should be dramatically lower. If not, as a Small or Medium sized Business
(SMB), you need to look around more.
1. Identifying a CM/ALM process
I
remember back in the 1970s and 1980s spending a substantial amount of time
trying to derive the best CM processes.
Back then, SCCS was the predominant model and that was nothing more than
a version control tool with some branching capabilities. Combine that with Make files and we had a
"CM system" - or so some thought.
Fortunately I worked for larger telecom companies back then and had time
to figure out that change packages were a necessity, that release stream-based
development was the natural way for a telecom project to progress, and that
version control (i.e. delta compression to a single file) was only a minor
part, at best, of CM. One of the most
successful proprietary CM tools of it's day, Mitel's SMS (Software Management
System), was up and running for years before delta compression was even
considered - and when it was introduced, there was no change to the user
interface, and no additional training - just some disk space savings - significant
though that was at the time.
We spent
a lot of time understanding what was necessary and what was not. We introduced problem tracking,
project/activity management, document management, and tied them all together in
with the rest of the CM system. After
carefully considering how change packaging had to work and how baseline
management could be automated from changes, we gradually built up our CM
tools. They were completed to the level
of true 2nd generation tools at a cost of well under a $1 million. And since they were in-house tools, we had
the flexibility to change them to work the way we wanted.
Unfortunately,
we were not, primarily, in the CM business.
Although the benefits easily justified the costs, the tools eventually
reached a level where the business case for continued changes was less and less
clear. After all, the tool did what we
wanted for the most part. So how could
we justify a team for second and third level feature requests?
The good
thing was that we were able to build a tool that matched the process elements
that we had decided were crucial. From
automating baselines, doing change-based configuration management, and ensuring
proper traceability between changes and features/problems, to ensuring we had
adequate reports showing us project progress, product quality (in terms of both
problems found and test case results), we had a process that helped us to
continually improve and tools that could be modified to support such
improvements.
We didn't
have starting points such as Sigma 6, CMM/CMMI, ISO 9001, or later
frameworks. Instead, we had experience -
from previous projects and from earlier iterations on our current
projects. We knew our processes and
tools would have to survive decades of use and would have to scale up.
The same
is not true today. We have some
excellent starting points for CM process.
These come from quality standards/frameworks, from tool vendors, from
experienced CM consultants and from places such as CM Crossroads. Identifying the requirements of a CM process
is no longer a large effort, but rather an engineering task of fitting
existing, fairly well known methods to our process requirements, and doing a
bit of customization to ensure the fit is snug.
2. Acquisition of Tools to Support CM/ALM
There are
still companies out there that decide that they need to build their own CM
tools - for whatever reason. Most of it
is NIH syndrome. There is very rarely a
need today for a company to build its own CM tool. In fact, there is a continuously smaller need
to knit together tools into a complete ALM solution. Even though there are still CM tools for
which you can dish out over $10K per seat, there are quite a selection of very
low cost (to free) tools that provide a significant CM benefit, and even full
ALM solutions for under $1K/user.
Small
businesses have to pay their employees, like everyone else. They can't afford not to invest $1K/user to
keep their competitive advantage. The
problem comes in knowing which tools to invest in to ensure that they are
getting an advantage without at the same time requiring a staff-up effort to
operate and support the tools. Many fall
into the trap of assuming that a freeware tool is the least expensive. In some cases this may be the case. But a full ALM solution is required by
companies small and large to effectively manage product development. Regardless of the cost, if the solution
requires significant up front resources (including training and initial data
population), significant operating administration, complex or tedious CM tasks
for CM managers and/or developers, significant tool integration/glue, etc. it
is not going to be suitable for small business.
Some of
the key drivers of 3rd generation CM/ALM technology address these issues. 3rd generation tools generally have a small
footprint, are easy to install, easy to populate from existing data, are easy
to use, and have a very low administrative requirement. As well, they have the basic set of CM/ALM
features that permit an organization to achieve a high level of process
maturity. A small business should look
only at 3rd generation or higher tools, or risk being swallowed up by the
tools/process. This is not to say that
there aren't some nifty, low administration 2nd generation tools out
there. But they do only part of the job
and you'll have to find other nifty tools to do the rest and then you have to
knit them together to get your full ALM solution. The cost in time in having to evaluate
multiple tools, having to knit them together and maintain upgrades to the whole
package is considerable.
3.
Customization of the tools to support the process
If you're
lucky, you'll find a tool that fits your process perfectly, and you'll find
that your process never needs to change.
But don't count on it. Even with
a high-end, mature CM capability and process, we've found that most
organizations need to change their process for one reason or another. Some high end tools have a high degree of
customization capability, but the customization capability is far from
trivial. You may need weeks of courses
and still have to spend a good deal of time making the changes. A small business can't afford this.
Instead,
look for a process-centric tool that also is easy to customize. The fact that it is process centric will
likely mean that the process is easy to adapt.
But process has many components:
object state flow, workflow/rules/triggers, permissions, data schema,
user interface and reports/queries. Your
process is specified in terms of roles, so your tools must allow customization
in terms of roles. The most important
thing from an ease-of-use perspective is "who sees what". You don't want your users wading through a
mass of complexity, and you don't want all roles seeing the same user
interface. Ideally, you want every
screen to have exactly what you want on it, without having to build your own
tool. But customization has to be
easy. You can't afford to bring in a
consultant to work on your tools when you barely have enough resources to focus
on your core business.
Now one
option, that you may find some tool vendors somewhat keen on, is to buy the
solution customized. That is, for a
small fee, or even included in the purchase price, they meet with you and
identify the key customizations needed, and implement them as part of the
"sales" process, so that you can evaluate the final product as part
of your evaluation. If the vendor has an
easy to customize tool, this is a no-brainer for the vendor. But if the tool is not easy to customize,
you'll find that the vendor won't agree to anything without an outrageous
consulting contract to go along with the tool purchase. This is one way to easily evaluate both the
vendor and the tool's customization capabilities, while at the same time
getting a more exact platform to evaluate.
4.
Training of personnel on the CM/ALM tools and process
If you're
a small business, you want to get a tool in, spend an hour or two with your
team familarizing them with the tool and then cut them loose. You don't want to have to spend days or even
weeks investing in training. Training
can easily be the highest up-front cost with some tools.
You do
want to spend some time ensuring that your team understands the process. But having understood the process, they
should be able to pick up the tool in no time.
Even better still, the tool should act as a guide to help your team
learn the process. It should let each
team member know what's on his or her to-do list. It should clearly show state flows and have
easy access to interactive process flow. Not many CM/ALM tools are going to do
this for you, but there are some out there, and even some that won't cost you
an arm and a leg. Even better, the tools
should provide on-line process help for your users and allow you to adjust the
process help easily as you change the process.
The goal
is to get your team up and running while learning the process. If the tools can help teach the process
that's all the better. If not, make sure
that you're aware of the costs involved.
Don't let a vendor tell you that you're having problems because you
didn't do enough training. And don't let
a vendor sell you canned training.
Training has to be customized to your organization. Look at options such as computer-aided
training, or low-cost custom training packages.
This is where it helps to work with the vendor to introduce your tool
customizations as part of the sales process.
5.
Training CM managers and administrators to support the process
You will
have to designate one or (preferably) two individuals to be the administrators
of your CM/ALM solution. In most small businesses, this person will also be
your CM manager. But what if you don't
have the budget to hire a CM manager.
Not to worry. There are a number
of tools out there that do not require anywhere near a full-time position for
the CM manager and administration job.
There are fewer such tools that also cover the ALM function adequately,
and even fewer that will cost-effectively allow the same person to adjust your
processes.
Training
of these personnel is typically a smaller overall expense, but a larger per
person expense. And how much can you
really afford to have these key personnel absent? Ideally, this training should be graduated -
you start off with a day or two (or a week or two with some tools), and are
able to keep the team running. Another
session and you can start improvements and introduce some automation. Another session and you can eliminate the
vendor loop for most issues and customizations.
As with
all roles, the key for CM managers and administrators is ease-of-use. But even more important is automation. Automation eliminates the need for the CM
manager and administrator except in extraordinary situations. Does your CM manager have to do labelling and
merging or is this automated? How are
baseline definitions put together? What do you have to do to identify what has
gone into a release? What about breaking
out a new release? Nightly builds? Development environment support? The more that can be automated, the smaller
the role for CM managers. And the same
goes for administrators. How is the
repository backed up? How much effort do upgrades involve? What about server operation, especially after
outages? Are there special recovery
procedures that have to be learned? The
more that is automated, the less need for administration, and the less chance
of human error.
The
Adminstrator's job should be to understand the tools enough so that if
something does go wrong, it can be quickly resolved. It should not be a fire-fighting role or a
tedious set of operations. It should not
involve having to be a database administrator.
And it should not be one of having to tune the tool and repository to
get adequate performance or scalability.
The CM
manager's job should involve taking decisions and acting on them with the
fewest clicks/keystrokes possible. In a
multiple product, stream-based change management environment, the CM manager
would ideally signal only the out-of-the-ordinary procedures. Nightly builds should run automatically based
on changes that have been promoted in each stream. Labelling should be automated based on the
actions and context/environments of the developers and based on decisions made
at the CRB. Perhaps the CM manager may
have to ask the system to freeze a baseline.
Perhaps ask the system to produce a set of tech-writer-ready release
notes. Perhaps kick-off a verification
or release process. Perhaps troubleshoot
when a developer accidentally puts the right code into the wrong development
stream. But normal day-to-day operations
should not require a lot of CM manager input.
As such, there should not be a lot of training required up front. A
quick hands-on run-through of the daily operations and maybe some customization
training. The point is, if it's a lot
more than that, then your small business is not going to be competitive because
you're using a greater percentage of your resources for non-core business.
For
customization, it may well be worth it to outsource customization to an expert,
if one can be found at SMB prices. But
if the customization is complex, you may be binding yourself to long term
contracts and costs. So look carefully
at your tools to see how much effort it is to customize. If you're basically programming to do
customization, watch out.
6.
Sufficient quality management to ensure the process is being followed and is
beneficial
The final
mile is the most difficult. And SMBs are
pre-disposed to thinking that when they see the first working lab model, that
they are into the final mile. The final
mile is shortened primarily by introducing effective process and quality
procedures into the first miles. But the
final mile will still be long. Even
after all of the features have been coded and unit tested, and even integrated
into a single deliverable, the verification begins. The problem reports follow. Then fixes.
Then a realization that some fixes will require a large rework. More testing, new problems introduced. And
the cycle continues until you know that the problem level is acceptable for
beta trials and eventually for delivery.
But you'll never know if you don't have your data and processes in
place. Yes there may be a few customers
who are willing to take a chance on you, but you had better not disappoint them
with poor quality. You had better be
certain about your deliveries or you'll rapidly get a bad reputation that won't
allow you to grow. Instead of reference
sites, you'll have horror stories.
So even
as an SMB, you'll need to ensure that you're doing adequate testing. You'll need to carefully track problems and
correct them. You'll need to be able to
verify that your process is being followed correctly so that the expected
benefits of the process are actually realized.
You'll need to ask your CM/ALM tools to show you what's right, what's
wrong, what's improving and what's not.
And the most crucial question for a release, in the case of a small
business, when do we switch from development mode to marketing and sales mode -
and you may want to do that before your product is absolutely ready to ship if
the sales cycle is long.
Again it
comes down to having good processes and advanced tools. Like it or not, 2nd generation CM/ALM tools
are not going to cut it for small businesses.
You'll have to make up what's lacking somewhere else. A successful entrepeneur will have the
knowledge necessary to make good decisions.
It's too easy to make the wrong decision based on gut feel. And in the case of SMBs, the wrong decision
could be the last decision. So even more
than for larger companies, CM/ALM is critical.
Wrong Way
I knew a
company, a spin-off smallish company, that started their development with a set
of experienced team members. They
resolved to do CM "the right way".
So they went off and bought the most expensive, market leading CM
tools. The company went bankrupt and the
cost of CM was no minor factor, especially when consulting costs were added in.
Out of
the ashes, sprung up a new company. They
were much more discerning about their CM tools and costs. They chose a very high end solution at a very
reasonable cost from a company that did not market themselves adequately, but
that they were familiar with from previous experience. The solution worked, cut their costs
dramatically, and not only did the job, but helped them to advance their
processes significantly.
This is
how a small business must address the CM market. Small businesses have high-end requirements,
even higher than large businesses because they have fewer resources to
spare. But there are solutions out
there. How much do you want to spend on
a implementing best practices using a top-of-the-line CM/ALM tool? Look around.
If the solution is too complex to evaluate, don't. If it looks free but is only a small piece,
beware.
Joe Farah is the President and CEO of Neuma Technology . 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 by email at farah@neuma.com
|