During my tenure here, project management has changed as much as anything else. It seems to be one of those areas that everyone intuitively understands is important but is also very difficult to make into a procedure. Many times we think that using a different software tool will suddenly clear up the muddy waters that project management produces. Our attempts at different systems (not just software but including that as a possible component of a new system) never really removed the mud but only moved it around so that we could see some mess under the surface.
The first complication to our otherwise ideal project management system is requirements. Only the simplest project has all of the requirements clearly identified at the beginning. Most of the time, projects begin with a general idea of what the completed product is supposed to do. Preliminary research and experimentation usually result in asking a question. The answer to each such question often becomes an additional requirement. The design process can map out many points at which these questions can occur. The project schedule cannot really predict how long it will take to answer a question that it does not know is coming.
Answering the questions leads to a couple of other things that influence project management, such as who answers the question? There are usually three different entities that could have a role in the answer.
The first is our engineering team who can sometimes answer the question. This means gathering the team for a meeting, but how often do those meetings result in a new experiment? Was the time for the meeting and the experiment included in the schedule?
Often, the customer must answer the question. You can give them options by saying we can do it like this or we can go this other way. Our current system tries to minimize giving a customer options like this by giving them a recommendation instead. Theoretically, this takes longer for us but decreases the customer response time. Regardless, the customer will need to take some steps to evaluate the recommendation. What if they don’t like the initial recommendation and you must pitch the second option?
The third entity is vendors. How frequently must a vendor answer a question with a quote? It might be the nature of our business but very few vendors can immediately provide a quote. Most people will do their best to work these additional requests into the schedule as quickly as possible but it still takes time.
A new phrase in our culture at HSI is “scope creep”. We intend to clearly define the scope of the project at the very beginning and then guard against deviation from it. On the surface this sounds great, but it is often hard to decide if the questions fall within the original scope. Those on the project side will usually say yes, however those on the management side will likely say no.
The other major hurdle to successful project management is priorities. With all the things on my plate on a daily basis, I work on the most pressing first. I will take it as far as I can and leave it on someone else’s plate. Then I go to the next project on my plate. What if this cycle extends the project into months or years? For the sake of this discussion, let’s assume enough time has passed since the project launch that the project in question is no longer the most pressing thing to that customer. How motivated are they to respond to your question? Each time this cycle takes longer. Everyone says they want to get this done and completely off the books but everyone has more pressing things to do. Contracts have already been signed; money has already changed hands, so the next step is deciding how to bring closure.
When I first came into the engineering department my supervisor required that each person provide an accomplishment list every other week. When we created a product development group and started charging customers for engineering development we wanted to be able to determine how many hours we spent on each project. To meet both of these goals, I record my day in 15 minute intervals in terms of the projects I touched and what I did on each project. At this point, our project management system does not require either list but I still keep it and will continue to do so. I don’t know how many times I have had to search that log to find the date we shipped samples or to guess how long this new project will take that was similar to another one in 2012.
I view my daily log as a filter that does work to remove some of the mud from my pool. The idea of “scope creep” is another filter. We will soon put language into our contracts about time limits on response that will give us permission to pull a project completely out of the queue. Even taken together there is still mud in our pool. Do you have other suggestions that help clear the water? As summer approaches it is high time to fully enjoy the pool.
