A Systems Approach To Project Management

There are many aspects of project management that are important and worthy of comment.  In this post I will present my thoughts on the value of having a system perspective in managing projects and some tools and techniques that can be helpful.  Keeping the big picture system perspective is harder than it sounds.  There are so many details that must be handled in order for a project to be successfully completed that it is easy to lose the forest for worrying about all of those trees.  To be able to handle the day to day details while still keeping your eye of the strategic whole is a demanding task but one that can be learned and improved.

A project is a temporary, one-time endeavor undertaken to solve a problem or take advantage of an opportunity.  It usually has a customer or customers (either internal or external to the organization that is doing the project), a budget or a set of scarce resources that must be managed and some kind of timeframe/constraint for completion or operation.  Before one can undertake a project to solve a problem one must first understand the problem.  Not only understand the details of the problem but also understand who has the problem and the context and environment that must be taken into consideration in addressing the problem.
In my experience the seeds of most project problems can be traced to sins of omission or commission in the early stages of the project even before it officially became a project.  This portion of the life cycle is often called the “fuzzy front end” (FFE) of the project.  A key practice in getting a handle on the “fuzzy front end” is to look at the problem from the customers and users perspectives.  What is important to customer? How will the user actually be using the system.  What does the world look like from their perspective?  What do they value and what is the solution worth?  Engineers tend to focus on features while customers are interested in benefits; how will this help them solve their problems.  One way to get this perspective is to spend time with the customers and users and enter into a dialog with them.  The key here is asking good open ended questions and then really listening (listening requires you to stop talking and telling the customer/user how great you and your company are).  Again, as technologists we often think that we know more than the customer and there is a tendency to be or at least appear to be arrogant.
 One tool I like a lot for dealing with the FFE is called quality function deployment (QFD) sometimes called the “house of quality”.  This tool is useful in linking customer wants and needs to functions that the system solution must perform.  There is a correlation matrix that links the two and there are three categories of correlation strong, medium and weak.  Strong correlations mean that this particular function is very important to the customer in one or more areas.  Correspondingly a weak correlation means that this function provides little benefit from the customer/users perspective (althought there may be other reasons to have it such as regulatory, etc.).  By have a graphical display it becomes easy to see what is important to the customer and why on a single page. 
For more information on QFD take a look at http://en.wikipedia.org/wiki/Quality_function_deployment.
 

Another tool that can help is rapid prototyping.  These prototypes are used not to prove out designs but instead are used to help define requirements and in particular user interface requirements.  The key here is to only  implement the key functionality, this keeps things simple and keeps the rapid in rapid prototyping.  It is also important to get the users who will actually use the product or service to have a hands on experience and get their feedback in as near to real time as possible.
 

One key to getting and keeping the system perspective is to make sure that you truly understand the problem before defining the solution.  One way to get this system view is to take a hierarchical approach to system development.  By breaking the project down into pieces in a tree structure such as a work breakdown structure (WBS) can be useful.  Have a functional hierarchy where instead of hardware solutions you put in functions that the solution must perform independent of how it will actually be performed.  This is called “what before how”; you must state what you want to do before you define how you are going to do it.  This helps keep the engineers from “diving for the weeds” and getting systems designed before the goals and objectives are even defined.  A good tool to use for developing these hierarchies is the Analytic Hierarch Process (AHP) developed by Tom Saaty from the University of Pittsburgh.  He has also developed a software program to go along with this www.expertchoice.com and there is a free trial version that you can download.  
 

This ability to keep from jumping to a point solution is a skill that must be developed with pratice.  One technique for accomplishing this is called staking the trade space.  This involves identifying several widely different possible solutions.  By having several viable solutions in play and looking at the problem in terms of these solutions keeps us from getting fixated and only looking at the problem from one perspective (if your only tool is a hammer everything looks like a nail).  This could mean having both a hardware and software solution or a combination of both.  This ability to know when not to make a decision is as important as knowing when a decision needs to be made.  This is kind of counter intuitive in that as project managers we are taught to make decisions so that it would seem logical that if a decision needs to be made the sooner we can make it the better.  But this can lead to the trap of the “point design” or reference configuration as it is sometimes called. 
 

The point design is a solution that we pick just so we can get more detail of the system solution to help define risks and do the costing and scheduling to make sure we are in the ballpark.  The trap is that we soon know much more about this particular solution than we do about any of the other alternatives.  When we are short on time and money them temptation to just forget the rest of the system trades and just pick this solution can become overwhelming.  So use the point design as a tool but don’t forget to keep the other alternatives in play as well.
 

These are some of the things that I have learned and found useful in my many years in project management and system engineering of complex systems.  More to come soon.