Adopting a Process -- Tips for Helping Your Team Adapt

So you have decided to adopt a more formal process for getting your projects done, congratulations. It is a good decision that will help you better manage your projects, make your team more efficient and improve your chances of coming in on schedule and on budget.

Most process methodologies do a fine job at covering the process; however they rarely address the real world issues encountered when a formal process collides with a team.

Each team is as unique as the individuals that comprise it and each will react differently to the new changes a formal process will require. These changes can often be viewed with skepticism or even outrage by team members comfortable doing things "their way".

Sure you can force it on them but without true buy in from the team the process will at best be ineffective and at worse create chaos.

The following tips will improve your chances of success in any process you adopt and provide a solid foundation for maturing it.

How much Process is enough?

While considered heresy by some process gurus this is a legitimate question. 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 team 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 prepared for can easily derail you. Here are some tips for 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 while 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?: 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.

To be successful you must achieve buy in and commitment to the process from everyone, this is key. 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. 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 Environment

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 a new process is forced on a team.

This doesn't 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. Processes are never 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.

Post Mortem Meetings

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 problems do not 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. Do not let anger and infighting fester into your next project.

-- Leave your ego at the door: No where are straight talk and the ability to provide and accept constructive criticism more crucial. 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.