Project Management -- Tips for Adopting a Better Process

Although many process descriptions do an excellent job of breaking down the various components of the process they rarely cover areas like how this affects your team, how much process to use or offer practical advice on issues encountered in the real world when trying to deploy one.

Following these fundamentals will improve your chances of success in any process you adopt and provide a solid foundation for maturing it.

What’s a Process and why do I need one?

Regardless of what business we are in, software, web site design or retail clothing, we all have a process we follow to complete a given project. When we talk about adopting a process we are talking about a more formal process.  A process is essentially an integrated set of roles, methods and techniques to in part, help achieve the following:

• Minimize risk.
• More accurately estimate your project schedule and budget.
• Detect problems early (upstream) instead of later (downstream) when they are much more expensive to fix, if they can be fixed at all.
• Better communication among team members regarding project scope, requirements and status.
• More accurately track the progress of the project and detect slippage early.
• Accomplish the project’s goals as efficiently and cost effectively as possible.

How much Process is enough?

The risk of trying to do too much too soon with a process can be as risky as not doing anything at all. Overloading your team with a new set of responsibilities and methods they are not accustomed to or ready for can easily derail you. Here are some tips of finding the right balance.

• Risk Factor. What is the project’s risk factor?  Obviously making software for an artificial heart is much more risky than deploying the third generation of a web site and the process, initially anyway, should match the risk. Be realistic about what your risks are, how expensive they will be to address downstream, and use this as a basis for deciding how much is required.

• How much can your team handle and what does it need most? To be successful you must achieve buy in and commitment to the process from everyone.  If you don’t your team will simply go through the motions and roll their collective eyes in project meetings. To overcome this find their pain points in how they work now and start with the areas of the process that directly address these.

• Roles and Responsibilities. Any process will have roles defined for each individual and it is critical that each person clearly understands the role they will be playing and feel they are comfortable in that role. Spend some time here and ask people if they are comfortable in their role, ask questions and listen!  Once your team is set, make sure they are empowered to do what they need to do and make sure everyone on the team is aware of who has a gun and a badge.

• Full Disclosure. The purpose of any process is to address problems as early (cheaply) as possible and this can only be done with visibility at every stage to accurately assess the status of the project. It is critical that team members are willing to admit mistakes, call out problems and do so in a way that does not create a hostile environment. Reward those who find fault in themselves and point out mistakes.  Often the tension can be cleared by starting with admitting your own mistakes first, others will follow, so lead by example and you will see that you can create an open environment were people feel free to view mistakes and even criticism constructively.

• Visibility. Similar to the above, visibility is all about people feeling comfortable disclosing information to the group.  Developers will want to sit on code until the last minute because they know it is not ready, designers hate people seeing unfinished work.  So understand why your developer or designer may be twitching as their early work is paraded in front of a group and tread lightly at first with criticism until they become more comfortable with this.  Phrases like; “This is really great but how about…” are invaluable, use them!

The Proper Tools

You can’t control what you can’t measure. So make sure you have the proper tools in place for both managing the process and being able to track and communicate about your project.

• Managing the Process. There are many excellent tools available for managing requirements, QA, and Development. Requirements management often gets the most attention but requirements can be easily managed in a word document while QA is often overlooked. A solid database that allows QA to track features from implementation to completion and any bugs that result will be invaluable for QA and development and the project as a whole.

• Tracking the Project. It is essential that your project manager is armed with a tool that can be used to show the progress of the project and its various comments.  Look for tools that allow the right level of detail (high level for management) and more detailed for individual departments and the project manager themselves. For example Microsoft Projectis an excellent tool for managing very strict rules driven projects. However many projects are exception driven, making strict project management tools difficult to use in a fluid changing environment.  A great alternative is scheduling calendar software like The Calendar Planner which provides the ability to manage various levels of detail in an easy to use calendar format.  Allowing project status to be easily communicated among the team.

Scope

Next to the Team environment this is probably the most critical aspect of any project.  You absolutely must focus on clearly defining scope at the earliest stages of development.

• Be realistic. Everyone wants everything right now, especially Sales and Marketing.  Ask tough questions early of these departments about what features your customers MUST have versus what they WANT to have. Make sure the company’s goals are represented at all times in requirements.  This is where the Vision document below comes in.

• Vision document. Think of it as a mission statement for the project itself.  This is where the company can clearly define what the goals are for the project. Who the stakeholders are and what the high level requirements are. Keep it HIGH level, details can come elsewhere. Make sure the requirements map to the goals and that as you move forward the work being done remains true to these goals and requirements.

• Don’t increase scope without adjusting your schedule and budget! Seems simple enough but probably the single most common mistake.  People always try to add “small” things that involve “minimal effort”.  These add up and the impact is often not addressed, which ultimately leads to a failure in schedule and budget.  The change board is your main defense against this, see change board below.

Requirements

Requirements in any project are tricky and many excellent books are dedicated to this subject alone. It is true that of the projects that fail most issues can be traced back to requirements.  Strange how this continues to be the case when requirements are the easiest and cheapest way to find and fix problems.

• A problem will never be cheaper than it is right now. When you review your requirements, you need to really review them, don’t just scan them.  Think about and try to visualize what they are saying.  You will often find problems are apparent at the surface.  Take the time to do thoughtful reviews and continue to refine the requirements until everyone feels they are correct. Compare the expense of re-writing a sentence in a word processor to re-writing hundreds of lines of code, re-testing and re-deploying and you’ll see these are the last chances you have at a cheap fix.

Change Boards

When done properly Change Boards can almost single-handedly manage even the most challenging projects.

• What it is. Very simply the change board is a meeting where each of the key departments and sometimes clients are represented and have a chance to discuss the project from every angle. The idea is to make sure everyone is aware of the status and is able to speak to the impact any change in requirements or schedule will have on their respective department.

• Who is there? Generally the list consists of the following: Marketing, Sales, QA, Operations, Development, IT, Project management, Clients.  Essentially everyone who has a stake in or is affected by the project. Depending on the nature of the project Marketing or Sales will often represent the client.  The most important rule here is, if someone is identified as a stakeholder in the project, do not have a meeting without them.  If they can’t be there, reschedule. 

Follow these steps in any process you adopt or any project you manage and you should find it really will improve your chances at success.