Employing a Software Development Process in Content Management Projects
February 26, 2004
One of the the lists I subscribe to is for technical writers and others in the technical communication field (techwr-l@lists.raycomm.com). I responded to a posting today that asked the list to weigh in on how engineers and technical writers can effectively collaborate as software is developed. You can imagine the problems technical writers face as software hurtles through the development process; can the documentation keep pace with such change?
As I point out in my reply, the poster asked the question and answered it, at least in part, because his organization has already identified that they need a more orderly development process, perhaps something along the lines of ISO 9001.
It occurred to me that the advice for keeping technical communicators in step with software development is identical to advice I would give to keep any stakeholder in step with a CMS implementation project. I welcome your thoughts.
What a great question, and even better that you answered it yourself already, because the answer is "process." I have worked for two successful software companies where we redesigned our process to conform to something like ISO 9001 and the Capability Maturity Model for Software (CMM, see some background herehttp://www.sei.cmu.edu/cmm/cmm.html, and note also that CMM is being sunsetted in favor of CMMI (Capability Maturity Model Integration)).
A great deal has been written about such processes, but I would like to offer some highlights of what I learned from going through the process twice--once on the customer support side of the business (including training and documentation) and once on the software development side of the business.
The highlights for me were:
- There should be detailed specifications (including functional and design specifications) that are highly readable and meaningful to all interested parties (including documentation).
- Such specifications should be subject to regular and formal reviews by all interested parties.
- Such specifications should be under a rigorous and visible change control process. (We even went so far as to have the Director of Customer Support, which included training and documentation, be one of the signatures on an approved change.)
- The entire product development process should be managed in visible and meaningful phases, and that transitions from phase to phase should be an explicit event. Thus, you don't consider the product to be in design phase until the functional specifications have been approved (pretty obvious, yes, but not always honored).
- Perhaps most importantly, that the transition from one phase to another be subject to an official declaration that the project has reached a state of readiness to be at the next stage. And that this state of readiness be defined by a number of meaningful criteria. (For instance, for release out of the design phase, you could require that the GUI be frozen; for release to Alpha that the installation scripts and documentation be complete. Again, pretty obvious, but the details are important.)
There is more of course (and I would be happy to discuss off line), but I think these highlights suggest the gist of it, which is that the software development process be orderly, open, and visible, and (here is the key) that all interested parties are fully involved and fully empowered to help manage the process to ensure their own organization's success in the ultimate release and use of the product.
One more quick thought. If you haven't already, you might consider an outside consultant to help your organization with this process. In one case, we did it on our own, and it worked because we had a _very_ senior and excellent engineering team. In the other case, we were all pretty junior, and we hired an outside consultant who did an excellent job of "herding the cats," as they say.
Hope this helps, and as I said, I would be happy to discuss offline.
Posted by Bill Trippe at February 26, 2004 10:02 PM
Comments
Hi Ian,
Thanks for your great post. A lot of people (perhaps the majority!) have a similar reaction to such process when they first hear about it. It really does sound dreary.
The good news is that it isn't. It's all about making the development process predictable and repeatable. So, indeed, it greatly helps with predicting cost, for example, as well as schedule. Such an approach also doesn't preclude rapid development or prototype development. Note that all of the stages and criteria I suggested are defined by the organization. You know your own process; the examples I cited are just that.
I would encourage you to look at the CMM/CMMI material I cited:
http://www.sei.cmu.edu/cmm/cmm.html
It explains it much better and more completely than I do.
Again, though, I appreciate your reaction. I had the same one myself. But after spending several years in development environments where we all ran around with our hair on fire, it was really a welcome change to have a process we all could articulate, exercise, and uphold. (Indeed, the first stage of "maturity" in the CMM is where development depends on heroic efforts (read, 100-hour weeks) and is driven by crisis. The second is where you have a process that is predictable and repeatable.)
Thanks again for your post, and I enjoyed reading some of your blog.
Bill
Posted by Bill Trippe at February 27, 2004 3:12 PMThe idea of using a methodology for managing CMS projects is a good one, but I think a more interesting approach is to combine Cooper's stage/gate product development methodology with an interative agile development process. Having used the waterfall methodology that you describe for many years, I found it to be unwieldy and not very "client friendly". Agile development or XP, on the other hand, is totally client driven and yields visible results more quickly. More importantly, at the end of the project, the requirements documentation (which is actually the test plans) actually matches the finished product.
Posted by Marc Strohlein at March 5, 2004 12:43 PMHi Marc,
It's good to see you, and thanks for weighing in. I have to admit to not having worked much with the methods you describe, though I like what I hear and read about agile development.
I am also glad you made a general point that I failed to make in my haste to support the waterfall method, I failed to simply say a process is better than the lack of one. Especially in the early days of Web content management, I saw many implementations fail because there was so essentially no process supporting it.
Posted by Bill Trippe at March 8, 2004 8:14 PMPost a comment
Comments for this entry have been closed.
That seems so heavy. I guess I haven't worked in an organization large enough to require that level of formality. But I can't really imagine making a good product that way either.
How can you come up with a functional specification without understanding the relative costs of development? How can you understand the costs without doing design? How can you fully understand the design without considering the implementation? And how can you consider the implementation without creating an implementation? (If you think it, you can write it -- if you can't write it, you haven't thought it through)
Or, as an individual in such a project, how can you make a positive effect on the product with all these barriers? I suspect, in fact, that you cannot -- you can meet specifications, but you cannot excede them. You can implement, but you cannot create. But then, many organizations are not looking for creativity -- at least not in every project. Makes for depressingly dull jobs, though.
Posted by Ian Bicking at February 27, 2004 1:59 PM