Project Management

Project manager develops rules for success

As project manager, what would you do differently if you had to repeat a difficult project? One TechRepublic member has put together this list of steps he would have taken during a "project from hell" to make things work.

By Bob Ivey

Editor’s note: This article comes from TechRepublic member Bob Ivey, who responded to a recent Tom Mochal column on project management. In this article, Ivey, a Pennsylvania-based project manager with 35 years of IT experience, discusses his experience during a recent, difficult project and makes several suggestions for avoiding similar mistakes in the future.

The question
In June, I left a project that I had been managing for about nine months. I have since been asking myself: What could I have done better to make the project a success on my watch, and what did I do wrong?

The project
The primary contractor brought me on as a subcontractor to manage a software development project that involved customizations to a vendor-supplied product using Visual Basic (VB) as the tool set. I was brought onto the project because of my expertise in the vendor product and my project management (PM) abilities.

Prior to my arrival, the two previous teams had performed the business analysis and had started the software development. Unfortunately, they had no experience with the purchased application, and scope creep was out of control. Further, the project was over budget and out of time.

These two teams had been let go and had left behind a fragmented collection of business analysis documents, an approved Statement of Work, and screen designs.

Picking up the pieces
Several weeks into my tenure, I discovered that the prime contractor had an extensively documented software development methodology with clear checkpoints and deliverables.

However, the marching orders from the program manager, to whom I reported directly, were to get the development done and not to be concerned with their internal methodology. Another subcontractor was to develop the testing and test plans, but that effort failed early on. Another team would handle training.

To get my arms around the problem, I spent a considerable amount of time reviewing the available documentation and the work done to date. I also did some use case modeling and developed a combination specification, design document, and Real Time Management system that was approved by the client, the prime contractor's customer, and received accolades from the prime contractor management.

Since I had little input to who did the work on the project, the project was staffed by very junior programmers who had no experience with the vendor application and little to no experience with VB. What was worse is that they missed every deliverable date and basically ignored any project plan—even ones to which they had agreed and had given assurances that they could meet the dates. Half of the staff were employees of the prime contractor and half were subcontractors.

I tried to make use of as much of the work done by the two previous teams as I could. I did, however, rearchitect the product to place more emphasis on VB and reduce any development using the vendor product's application program interface. The program manager agreed with this strategy.

The original program manager, however, took another assignment and was replaced by a mean-spirited person who subsequently took over my duties as PM—even though this person lacked the technical expertise that I was brought on to provide.

After several rounds of staffing changes, I managed to get the development done, but difficulty developed over the unit testing process. Since the prime contractor did not provide either equipment or personnel to perform the testing, I was left with no choice but to put together a plan to use the development staff along with some help from the client to do the testing.

The new program manager then began a campaign to make me a scapegoat because an audit showed that the company's software development process was not followed for this project.

The solution
Based on this disaster, I have identified some actions I would take to prevent a repeat of this "project from hell":
  1. Scrap the software development that had been done previously and lay out a new architecture with a corresponding detailed design document.
  2. Establish a more modular development approach, where each module is designed to perform a specific function and requires individual module testing. This would have made the project easier and clearer for the junior programmers to work on, and it would have improved individual programmer accountability and project tracking. Technically, this approach would also have reduced the software configuration management problems we had with Visual Source Safe—handling concurrent development on a single module by multiple developers, integration problems with Visual Basic during the creation of the executable code, occasionally hanging up and losing code—which was clearly not up to the task.
  3. Assign a senior developer to perform the module integration.
  4. Assume less in the way of programmer skill level or professionalism. I mistakenly thought that the programmers had knowledge of such things as programming guidelines (use of strong data typing, variable naming, commenting, error processing, etc.), understanding of Use Case diagrams or methodology, and formal testing methodologies.
  5. Implement a peer code-review process.
  6. Insist on a written document between my company and the prime contractor that detailed the roles, expectations, and completion criteria of the project—including the use of the prime contractor's development process or exclusion thereof—and the software development process that is to be used.
  7. Push harder and earlier in the project to solve the problem of providing independent testing resources.

Bottom line
I believe now that implementing a solid foundation of PM policies and procedures early in your tenure is key. Trying to react by applying another major PM tactic out of your bag of tricks seems to increase confusion. Small corrective measures as the project progresses may, however, be necessary and prove more successful.

What rules, written or unwritten, do you follow?
As a project manager, are there rules that you follow—and have learned to stick to through unhappy projects—that help make your work successful?Share them with us in a discussion below.


Editor's Picks