A project manager must be a good problem solver/Good planner

If you wanted to summarize a good project manager in a single short phrase, I believe that phrase would be: problem solver.

At every stage, projects have problems (or opportunities as some say). The good project managers are those who can keep the project moving along by solving those problems.

Having said that, clearly it is also true that the best projects have fewer problems than the projects which are not-so-good. The best way to minimize the number of problems is by planning for them. So, working hand-in-hand with the ability to solve problems is the ability to plan the project well enough that problems don’t occur in the first place. The two skills are nearly inseparable. I have known successful project managers who are good planners but less skillful at solving problems. I also know of successful project manager who are rotten at planning but can quickly solve every problem that comes around.

The members of the project team generally prefer the better planners, unless they really crave excitement.

Not surprisingly the very best project managers have both skills. They plan well and they can quickly solve the relatively few problems which, inevitably, do surface.

Much of the rest of this book focuses on planning the project (getting the requirements together and documenting them well, planning resources and so on). So in this section of the book, I will focus on problem solving.

One of the keys to good problem solving is simply knowing who knows what. In particular it is important to know who the experts are – particularly who are the experts that you can trust. If you have a database question, who is the best person to ask about databases? If you have a network problem, who is the best person to ask about networks?

These experts don’t necessarily have to be people working on your project, though that would be ideal. However if the expert is not working on your project, you need to understand that the expert’s time is valuable and you should treat it as such. But most people don’t mind offering advice when someone seeks them out as an expert. That sort of advice can help start the problem solving in the right direction and often requires only a few minutes of discussion in order to get some beginning advice. If you are completely unfamiliar with a particular problem that arises, it is good to at least get an initial assessment of whether or not the problem is serious or not.

This is another reason why it is good to have technical project managers. Sometimes they can act as their own problem-solving experts. But, in general, for many reasons, the best plan is to involve the project team in developing solutions to problems.

Some technical problems lend themselves to very obvious solutions. But even those obvious solutions may require extra analysis.

I worked for a while for a company that was investing millions of dollars in a new “standard” software program which replaced an older existing program. The software architects decided to use something called an “object-oriented database”. That database made it easier to develop code. The problem was that the database did not scale well. In other words as the database got larger and larger the performance suffered considerably.

Initially there were no real performance issues. Then when problems with performance started to appear as more data was added to the database, an obvious solution was selected: buy faster and faster hardware. Eventually, every couple of months, they were buying the best and fastest processor and system that they could find and were reconfiguring it and doing their testing on that system. They were fighting a losing battle, of course. Over time, even on their state-of-the-art machines, the new software systems were taking more than a day to perform operations that took the older system less than an hour to perform using much slower hardware. Ultimately the designers chose the only possible alternative – redesign the system with a different type of database (i.e. one that was not object-oriented). Unfortunately the type of database in use was a key part of every software component so the software was delayed by over a year and millions of dollars were lost. (A number of people lost their jobs as well.)

In retrospect, the change of database designs should have been made earlier in the development process. The initial decision to simply continuously select newer and faster software should have been done only after much more analysis which should have begun at least when the problem was first detected. In this specific instance, I would blame the project manager more than I would the software architects for not making the decision to change the design earlier. I wouldn’t necessarily blame the project manager for the initial decision to use an object-oriented database. There probably should have been some questions asked about performance before the design was completed because the technical specification included some performance goals. But once the problem was identified, it was important to come up with the best solution that would not have caused so much time and money to be wasted. Simply buying faster and faster hardware was easy and relatively straightforward, but it was not that “best” solution.

As an aside, in this specific example, the project manager may have to take more of the responsibility than in other technical designs. I’ve already emphasized the need for project managers on technical projects to have a good technical background of their own. But I don’t believe that it is necessary for the project manager to be the best technical person working on the project. To some extent the project manager really does have to depend on his or her technical staff to make the best technical decisions.

But an object-oriented database was a new technology which had not been used before on any project developed at that particular company. As such the use of such a database should have been recognized as a significant risk. Because of that risk the project manager should have initiated some research by the project team, particularly the project team leads, to see what problems may be associated with that new technology. Talking to other customers of that database product is a good first step but there are other ways to do such research. While things have changed quite a bit in the last decade since this situation first arose, the inability of these databases to scale as the amount of data contained in them increases should have been apparent early in that research. The problem could have –and should have – been identified before it was first used as a component in the design.

Custom software projects often don’t have the luxury of performing such research. It costs time and money which can cut directly into the profit margins of the project itself. Because of that it often a good idea to be very cautious when implementing new technologies in custom software projects. Fortunately it is often the case that the customer will make recommendations of the technology that they would like to use. If a new technology is recommended, then the customer implicitly assumes a portion of the risk of using that new technology.

That’s all fine and good. But, if a problem has not been discovered until after development was begun, how should that problem be handled?

In the object-oriented-database example, once it was discovered that the performance of the system was not matching the specifications, the project team should have done an analysis. (In this example they didn’t really analyze the reasons for the bad performance; instead they just figured that faster hardware would solve the problem. Temporarily, at least, it did. But the improvements in hardware performance did not keep pace with the need for faster hardware which was based on the number of objects in the database.)

The analysis should have compared the previous system design with the new design. The comparison should have recognized that the difference was due to a lack of performance in the database. The database, as a single component, could then have been tested under more and more stringent conditions and found not to scale well.

Note that testing such as I suggest doesn’t generally take a great deal of time or effort. System bottlenecks tend to be pretty obvious and generally don’t change much.

How do you solve problems such as this?

There are many methods which people use to solve problems. There are also many different types of problems which can appear on projects. On some projects there may be non-technical problems such as an unresponsive customer. Or you may have two project team members who don’t work well with each other because of some personality conflict.

But the most common problems are technical, so I would prefer to focus the discussion on those.

The best way to solve a technical problem is with the help of the technical team. Some people only like to engage the help of the technical leads on the project. If the problem is relatively minor, that’s probably the best way to handle it. It doesn’t make much sense to involve the entire technical staff in resolving every problem.

But with a larger problem, such as the object-oriented database problem described previously, I much prefer to ask for the ideas of the entire technical team, or at least those individuals involved in the specific area where the problem is occurring. I doubt, for example, that I would get the hardware engineers involved in solving a software problem, though I might even do that under special circumstances.

But when solving a problem, unless the solution is very obvious (such as insufficient test data provided by the customer) the more ideas you have the better. Often the first idea discussed may not provide the solution but it may stimulate another idea which turns out to be the best solution.

Additionally, for the major problems, it may very well have been the project leads whose designs caused the problem in the first place.

If at all possible I also prefer to get the ideas and opinions of how to solve a particular problem in an informal and private environment. As we found out when discussing the personalities of software developers, they tend to be very introverted. Many of them might be unwilling to express their opinion in a large group, particularly if it is critical and may cause some conflict between individuals. But if you talk to them privately and in a non-confrontational manner, you are much more likely to get honest suggestions for solutions.

Hopefully, after talking with the members of the project team, one or more ideas for solutions to the current problem will have been suggested. If none of the ideas seem to be adequate or you have no ideas at all, then the search needs to be extended beyond the members of the project team. In such a case, you could ask for the opinion of others within your company who are working on similar projects or you could hire an outside consultant to help provide possible solutions. (The outside consultant could be expensive and could also, quite possibly, take quite a while to understand the problem well enough to offer possible solutions.)

Once you have a list of possible solutions, you should analyze them for ease (i.e. expense) of implementation and risk. This is another example of an instance where having a project manager with a technical background helps when managing technical projects.

Then discuss them in a meeting with the project team.

The meeting should be open and frank with everyone invited who contributed a possible solution for the problem. Some attempts should be made to quantify the effects on cost and schedule for implementing each of the proposed solution. If any changes to the technical requirements (i.e. the “spec”) would be required, those should be identified as well.

At this point in this discussion, it is important to remember that when a serious problem which needs correction occurs on a project, in nearly every case a compromise of some type must be made with the three key project deliverables: specification, schedule and budget. Often, in fact, more than one of those deliverables will have to be compromised.

Such problems do occur on almost any project. That’s why contingency should be built into the project plan for both schedule and budget (even occasionally for specification). Even when you do that, there are times that the technical problems exceed the planned for contingency.

On a custom software project, I contend that the least important factor is budget. If you can deliver a solution that meets schedule and specification then the customer will probably come back to you for future enhancements. There’s a good chance that you’ll get the money back in the long run. However if you do something to make the customer unhappy with what you’ve delivered, you’ve severely hurt your long-term relationship with that customer.

In the example of the poorly performing, object-oriented database problem that I described earlier.

Clearly the second time through the process you should do some testing.