The Rational Unified Process, Enterprise Unified Process, Agile Development Methodologies, Unified Modeling Languages. They come in many names, complexities and sizes but following one will help ensure success on your next project.

This article is not a detailed overview of a formal process. Instead it provides an overview of the most critical components common to each, as well as some tips on successfully deploying them. 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.

It can be very helpful as a beginner’s introduction to process and can help you more easily grasp some of the concepts you will be introduced to. For the more experienced process guru it should have some helpful tips on smoothing over some of the rough edges we all deal with from time to time.

The information here is based on experiences and lessons learned in over 15 years of developing and managing over 100 complex project releases.

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. Sometimes it works and sometimes it does not, often with costly results. 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.

Formal processes are often created and refined over years of trial and error to attempt to create an ideal “recipe” for having an optimal chance at successfully completing any project. While they were developed for and commonly used in Software Development, Aerospace and engineering, most of the core concepts are not specific to these or any industry and anyone can benefit from using them.

How much Process is enough? It is critical to the success of any process to understand how much you initially need to bite off. The risk of trying to do too much too soon with a process can be as risky as not doing anything at all, especially if you are a more agile company trying to make the transition to being more process oriented. Overloading your team with a new set of responsibilities and methods they are not accustomed to or ready for can easily derail you. However if you don’t start changing you will continue to have the same problems. 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. The former would need extensive, redundant and exhaustive QA checks and balances where the latter can be easily adjusted on the fly after deployment with no loss of life. 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. No one knows your environment, project and team better than you, so use some common sense in deciding what feels right.

* How much can your team handle and what does it need most? The impact on the team is often overlooked. Any process is only as good as what your team can manage and regardless of the ultimate benefits, initially it will cause additional effort in training and new tasks your team is not accustomed to managing. 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.

* Start Small. Start with a few areas that you feel are critical, again including pain points so your team sees immediate benefits. It will be easier to add more process layers later when they see it as a benefit and not simply extra layers of bureaucracy. Gaining buy in is critical and if you start small your team will have a chance to get their collective heads around this as well as see the benefits, making more maturation downstream easier.

Team and Environment
One of the most commonly overlooked elements of employing or maturing a process is the team itself. Each team has a different dynamic and will respond very differently to various aspects of what you are trying to do. Too often, out of frustration with problems new process is forced on a team. This does not mean your team should dictate your process, but as mentioned above your team’s buy in to what you are doing is essential for your success. I have never seen a process successfully steamrolled over a team. So tread carefully, get your team involved in discussions about what you are doing and why, it will pay dividends.

* 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. If your developers refuse to tell your project manager the information they need you will have a problem. If the project manager reacts by dropping soft milestones into your project plan you have a problem you won’t even know about until it is too late. So make sure roles are clearly defined for everyone and that everyone knows who has power on the team.

* Full Disclosure. Enough cannot be said about this. 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. Developer egos, team infighting, and defensive posturing all create an environment where no process can be effective. 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. To do this you must bring the parties together and openly discuss this issue. Address the fact that issues are brought up for the overall good of the project and organization. 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 fundamental goal of any good process is catching issues as early in the process as possible. So you must discuss this with your team and make sure everyone understands that this can only be done with full visibility on all aspects of the project.

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. As with the process itself make a call on how much you need before you dive in and start buying. Shore up critical parts of the process. 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 Project for example is 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. The biggest mistake is usually trying to do too much on too short a schedule or budget or defining the scope and then not adhering to it. This frustrates developers and ultimately throws the project into chaos.

* 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. Sometimes you will find marketers have made promises to a single client and are trying to save face when in the grand scheme the feature is not as important to the company’s goals. Focus on what you truly must do, let them know they can’t have everything and force them to choose. Make sure the company’s goals are represented at all times in requirements. This is where the Vision document below comes in.

* Vision document. These may have various names for different methodologies but a vision document is essentially a high level overview of your project. 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. This will be your primary document for setting the scope of the project. 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. That can change but only when the stakeholders agree and sign off on the changes.

* 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.

* Get your customers involved, early! Make sure customers are involved in the earliest stages of requirements and keep them involved. Often a customer requests something and then developers disappear to figure it out. Big mistake! Come back to your clients with explanations of how you envision the feature and use mockups whenever possible so they can visualize it. You will find that making even a simple drawing of something will not only allow the customer to grasp it more easily but you will quickly spot problems you haven’t considered.

* QA starts at requirements. QA should be involved at the beginning not just the end of the project as is so often the case. Let them freely review Vision documents and requirements. They will often view potential issues that other departments may miss.

Change Boards
When done properly Change Boards can almost single-handedly manage even the most challenging projects. However if you don’t have the correct team environment in place as mentioned above, they will be ineffective at best and at worst will create more animosity.

* 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.

* Where to start? A great way to start is usually to have everyone provide a brief update on what they are doing regarding the project. This helps remove the dark corners, often points out areas of disconnect and helps ease the tension of these sometimes contentious meetings by giving everyone an easy topic to cover and maybe brag a bit to start.

* Where to focus? The key issue in early change board meetings is scope. What is in and what is out? This will be a push and pull between what Sales and Marketing want and what those responsible for delivering can handle. After the scope settles down it is about status. Are the Requirements still correct? Have priorities adjusted? Are we on target? Most importantly each group is represented so if Marketing says: “I must have this”, Development is there to speak to the impact of this on the schedule, in real time. Again it promotes visibility and keeps things from being changed without everyone being able to speak to the ramifications. It simultaneously controls and informs.

* How often? They are very useful so have them as often as you need. This will depend on the nature of the project but every 1-2 weeks is best. Longer and you start to have too little communication and too many potential areas for slippage, any more frequent and you eat into too much work time.

* What not to do. Do not allow the meeting to descend into arguments and finger pointing. The change board is a tool that serves all departments. It is essential it remains a place where people can talk openly about issues. It is a place for reality, not spin. This will be harder than it sounds at times but resist the temptation to avoid them. There is no meeting more important to the success of a project than these.

Post Mortem
The Post Mortem is a meeting to get together after the project has completed. This is not a post release party although depending on the success it may have that atmosphere. It is a chance for some straight talk on what went wrong and more importantly how to address that in the future. Everyone lines up for Post Mortems when things went well but you can learn more from you failures than your successes. So if you had a lot of problems don’t miss this opportunity to address them when they are still fresh in everyone’s mind! Also, Teams need a sense of closure and this helps them do that as well as vent so you can clear the air before you next project starts.

* Leave your ego at the door. No where are straight talk and the ability to provide and accept constructive criticism more critical. This meeting cannot be about egos, or CYA, it has to a frank discussion about the mistakes made by everyone (we all make them) or areas in the process that need to be improved. Again to set the tone try leading off the meeting by the most senior person in the room discussing mistakes they made or things they learned. It really helps set the right tone and ease the tension.

* Take Notes, Then Action. This is the time to learn and too often people discuss the issues then go off and do nothing. This is the chance to take corrective action to save you time and money on the next project. So take copious notes and put them into action while the iron is hot.

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.