system analyst and adjunct cio business analyst and technical writer

 Home  Who We Help  Services  Approach  Case Studies  Resources  Contacts  About Us


» Do you follow a formal or informal software development process today?
» If so, does you staff understand how it works and how to employ it?
» Have you evaluated any of the newer methodologies like eXtreme Programming?

Answered no to any of these?

We can help.


The best process for a project is the simplest process that makes the project successful.

The challenge in defining and implementing a process is finding the simplest one. Our first task is to define both process and simplest.

According to Wordsmyth, a process is "a systematic sequence of actions used to produce something or achieve an end". A process consists of a set of tasks, phases, stages, methods, techniques, procedures and/or practices that people use to conduct a set of activities. Those activities result in producing or accomplishing something of value to someone.

Simplest is easier to define. How about "not complex or difficult; easily done or understood" also taken from Wordsmyth?

Keep it simple.

So your goal is to identify a sequence of actions that are not difficult to do or understand yet get the job done successfully. (We'll discuss how one goes about measuring success another time!) A process that is too complex will add many additional steps and tasks requiring a large expenditure of time and/or money. However, a process that is too easy will not provide enough discipline or checkpoints resulting in chaos. In either case, the people working on the project will be stressed, strained and stymied.

There are two organizations that seek to measure process effectiveness. It's important to note that they do NOT define or support any particular process. They evaluate an existing process. The first organization of note is the International Organization for Standardization (ISO, yes it should be IOS but it's not!) and their ISO 9000 certification standard. ISO 9000 is sought primarily by manufacturing companies to ensure that the products they build are of uniform quality. You'll note that the operative word is "uniform". The level of quality is up to the people defining the process.

The second organization is the Software Engineering Institute (SEI) and their Capability Maturity Model (CMM). The SEI is affiliated with Carnegie Mellon University. The CMM targets software development and defines five levels of process maturity. The first level represents little or no process and the fifth level represents a rigorous, disciplined and well-defined process.

So now you know how processes can be measured, but how do you create one? We'll focus on software development processes because we happen to be experts in the field. Here's how you might go about improving or creating a software development process.

Research Existing Processes

There are several well-known and widely-used software development processes (sometimes a process is referred to as a methodology). Our favorites are (in alphabetical order):

These vary from very simple, short-term oriented (Scrum) to very complex, long-term focused (Rational Unified Process). You could just pick one and start using it or you could roll your own based on some combination of ideas. This is where it gets complicated.

Establish Goals and Objectives
You want process not bureaucracy!

Answers to these questions will guide you toward a process that meets your needs without creating excessive disruption or adding too much fixed cost. You also need to consider that going from an ad-hoc process (a nice way of saying total chaos) to a structured methodology will take time, training and teamwork. You won't get there during the course of a single project.

Start by reviewing the simpler processes such as XP (eXtreme Programming) and Scrum. If you feel more rigor is needed, take a look at RUP (Rational Unified Process) and OPEN (Object-oriented Process, Environment and Notation). Keep the following points in mind during your research:

Select and Implement the New Process

Once you've decided on a process, you'll need to select elements of the process to be implemented first. We're sure you've heard the old adage about real estate. (For those that haven't ... There are three critical factors to selecting real estate, location, location and location.). Likewise, there are three critical factors to completing any project successfully, planning, planning and planning. Initially, focus on elements of the new process that will help improve project planning. Start with high-level plans and drill down to individual tasks.

The next critical items are process elements that monitor and communicate the plans. We encourage you to circulate planning documents and keep everyone informed. That doesn't mean soliciting changes from anyone and everyone. It means letting people know what decisions have been made.

Finally, and most importantly, once a plan is defined impress upon everyone that they must STICK TO THE PLAN. Deviations from the plan should be strongly discouraged without project management approval. Yes, plans always change AND change is to be embraced. However, change must also be monitored and controlled or your new process will quickly degenerate into uncontrolled frenzy.

Good luck with your process efforts. If you have any questions or comments, please contact us at any time.

If you'd like to know more about our project team services, please take a look at our Hands-On Mentoring Program.

Process Pitfalls

Beware of Critics!

Every process or methodology has it's critics. Waterfall is too slow to react. Iterative never ends. Spiral goes around in circles. Scrum and XP ignore architecture. RUP is too big and bulky.

All these comments are specific situations.

No single process works in all circumstances. A waterfall approach (ie. not iterative) works when solving well-understood problems with an experienced team. In the face of great uncertainty and/or an inexperienced team, waterfall will fail.

Conversely, iterative approaches like Scrum and XP are best when there is an abundance of unknowns and/or the team lacks proper experience.

You might consider starting a project using a waterfall or RUP (with its focus on architecture) approach and switch to Scrum or XP once requirements and architecture are defined. There is no one size fits all.

For these reasons, you should consider adopting a flexible methodology for your firm. Define many steps and deliverables. Choose those that are best suited to the project at hand. Make sure some steps and2003-2009 DAMICON deliverables are mandatory for all projects!

Good luck!