Process Trumps Technology

The concept I was going for when I came up with this title is loosely based on what I, for some reason, remembered was a Bible verse, but it is really a Chinese proverb.  “Give a man a fish and you feed him for a day.  Teach a man to fish, and you feed him for a lifetime.”

The Method, Not the Means

I believe the same holds true for process vs. technology.  Right now somewhere there is a wife buying her husband some cool new tool to entice him to do a job around the house that can be done a number of different ways with a number of different materials.  I know it worked for me…but in the long run it didn’t really motivate me beyond the initial task at hand.

No amount of cool software will replace good sound fundamentals when it comes to creating repeatable processes that can be taken to the masses in an organization and help take it to the next level.  For example, there are nice requirements management tools out there, but if a customer or a project team has no clue how to capture requirements and can’t follow a process to get from requirements definition to actually developing a solution, then the project will fail no matter what requirements capture method or methodology is use.

PMI and PMP promoters would say this is where like-mindedness and common dialogue helps an organization create those repeatable processes and helps keep all project managers in an organization traveling down a similar path.  It allows the organization to put the same face on each project, remain consistent and create the same type of customer experience for each customer and for returning customers…and thus, likely creating greater customer satisfaction.

I don’t disagree with that statement, though I also don’t think it is the only way to get there.  Experienced project managers bring invaluable knowledge to the table and can also easily adapt to sound project management methodology and principles.

Enough about that though…I’m heading down the wrong path again.  What I’m trying to say here is that when managing a project, know the following:

• What the end solution needs to accomplish – this will help the team determine the best technology to use to accomplish the end goal

• What information needs to be captured and presented – this will enable the project manager to utilize the best software or technology to deliver information in a timely and understandable manner

When I was serving in the role of Sr. Project Manager at Rockwell Collins, I was required to present larger, more visible projects to a Technology Council comprised of leaders within the organization.  The goal of the council was to help ensure that the proper technology was being used for the solution because many customers pushed for a particular technical solution that may not be in the best interest of the project or the corporation (these were internal projects for internal business units, for the most part).  By presenting a high-level view of the project and a proposed solution to the council, we could jointly decide on these larger projects what the proper solution should be.  We had a good process in place, which allowed us to utilize the best technology for each project.  Process first, technology second.

Summary

If the proper process and practices are in place and skilled resources – such as an experienced project manager and skilled project team members – are leading the effort, then the technology is almost an afterthought.  If you allow technology to drive the solution, then the possibility of delivering a solution to the customer that does not fully meet their needs is infinitely higher thus increasing the likelihood of customer dissatisfaction overall.

Case Study: Requirements Management in the Automotive Industry

I would like to share another recent article from InformationWeek. This one concerns how an auto parts manufacturer is managing their parts requirements in a single repository and how critical it is for their teams around the world as they work to both ensure requirements compliance and reduce the costs of re-work and re-engineering that can occur when requirements change and something is missed along the way.

I found this an interesting twist to my experience managing requirements for IT projects and how it’s really not that different – requirements are requirements and they are definitely the lifeblood of a project. You already know I feel this way if you read my previous article entitled, not surprisingly, “Requirements are the Lifeblood of the Project.”

Please, read on….

Delphi Engineers Use a Single Requirements Repository

Requirements management discipline isn’t just for managing code. At auto component maker Delphi, the strategy that developers use to get software right is the same one used to manage all the requirements an automaker gives the company to build a particular piece of a vehicle.

Delphi has created a single repository for all requirements of a given component, helping Delphi’s 1,500 software, electrical, and other engineers discuss and comply with requirements, even when those people are spread around the world, including its 22 software development sites. The repository, based on IBM’s Doors software, also is used for search – for example, to trace details about where within the software architecture and code a particular required function shows up.

“It’s a fairly complex scheme to track requirements, where they were implemented, tested,” says Cory Wentz, Delphi’s lead engineer on the project, and this system “provides the backbone for this.” For a typical vehicle, Delphi can get about 300 different electronic documents, each with 20-30 pages, and the requirements Delphi needs to work may be spread throughout many places in the documents. Besides having search, a central repository lets Delphi engineers compare original specs against changes the customer made along the way.

It’s critical work because if engineers misinterpret or overlook a requirement, or fail to incorporate new requirements that customers frequently add, Delphi must rework the design – which can burn a month of two, says Wentz, and add anywhere from tens to hundreds of thousands of dollars in new design costs, depending on the importance of the requirements. In an industry hit as hard as automotive, he says, “reducing engineering costs is critical for survival.”

This article, originally entitled “Delphi Engineers Use Single Repository,” was written by Marianne Kolbasuk McGee and appeared in the June 8, 2009 issue of InformationWeek.