| So you have decided to adopt a more formal | | | | Once your team is set, make sure they are |
| process for getting your projects done, | | | | empowered to do what they need to do and make |
| congratulations. It is a good decision that will help you | | | | sure everyone on the team is aware of who has a |
| better manage your projects, make your team more | | | | gun and a badge. |
| efficient and improve your chances of coming in on | | | | If your developers refuse to tell your project |
| schedule and on budget. | | | | manager the information they need you will have a |
| Most process methodologies do a fine job at | | | | problem. If the project manager reacts by dropping |
| covering the process; however they rarely address | | | | soft milestones into your project plan you have a |
| the real world issues encountered when a formal | | | | problem you won't even know about until it is too |
| process collides with a team. | | | | late. |
| Each team is as unique as the individuals that | | | | So make sure roles are clearly defined for everyone |
| comprise it and each will react differently to the new | | | | and that everyone knows who has power on the |
| changes a formal process will require. These changes | | | | team. |
| can often be viewed with skepticism or even | | | | -- Full Disclosure: Enough cannot be said about this. |
| outrage by team members comfortable doing things | | | | The purpose of any process is to address problems |
| "their way". | | | | as early (cheaply) as possible and this can only be |
| Sure you can force it on them but without true buy | | | | done with visibility at every stage to accurately |
| in from the team the process will at best be | | | | assess the status of the project. |
| ineffective and at worse create chaos. | | | | Developer egos, team infighting, and defensive |
| The following tips will improve your chances of | | | | posturing all create an environment where no process |
| success in any process you adopt and provide a solid | | | | can be effective. It is critical that team members are |
| foundation for maturing it. | | | | willing to admit mistakes, call out problems and do so |
| How much Process is enough? | | | | in a way that does not create a hostile environment. |
| While considered heresy by some process gurus this | | | | To do this you must bring the parties together and |
| is a legitimate question. The risk of trying to do too | | | | openly discuss this issue. Address the fact that issues |
| much too soon with a process can be as risky as not | | | | are brought up for the overall good of the project |
| doing anything at all, especially if you are a more agile | | | | and organization. |
| team trying to make the transition to being more | | | | Reward those who find fault in themselves and point |
| process oriented. | | | | out mistakes. Often the tension can be cleared by |
| Overloading your team with a new set of | | | | starting with admitting your own mistakes first, |
| responsibilities and methods they are not accustomed | | | | others will follow, so lead by example and you will |
| to or prepared for can easily derail you. Here are | | | | see that you can create an open environment were |
| some tips for finding the right balance. | | | | people feel free to view mistakes and even criticism |
| -- Risk Factor: What is the project's risk factor? | | | | constructively. |
| Obviously making software for an artificial heart is | | | | -- Visibility: Similar to the above, visibility is all about |
| much more risky than deploying the third generation | | | | people feeling comfortable disclosing information to |
| of a web site and the process, initially anyway, should | | | | the group. Developers will want to sit on code until |
| match the risk. The former would need extensive, | | | | the last minute because they know it is not ready, |
| redundant and exhaustive QA checks and balances | | | | designers hate people seeing unfinished work. |
| while the latter can be easily adjusted on the fly | | | | So understand why your developer or designer may |
| after deployment with no loss of life. | | | | be twitching as their early work is paraded in front of |
| Be realistic about what your risks are, how expensive | | | | a group and tread lightly at first with criticism until |
| they will be to address downstream, and use this as | | | | they become more comfortable with this. Phrases |
| a basis for deciding how much is required. No one | | | | like; "This is really great but how about..." are |
| knows your environment, project and team better | | | | invaluable, use them! |
| than you, so use some common sense in deciding | | | | The fundamental goal of any good process is |
| what feels right. | | | | catching issues as early in the process as possible. So |
| -- How much can your team handle and what does it | | | | you must discuss this with your team and make sure |
| need most?: Any process is only as good as what | | | | everyone understands that this can only be done |
| your team can manage and regardless of the | | | | with full visibility on all aspects of the project. |
| ultimate benefits, initially it will cause additional effort | | | | Post Mortem Meetings |
| in training and new tasks your team is not | | | | The Post Mortem is a meeting to get together after |
| accustomed to. | | | | the project has completed. This is not a post release |
| To be successful you must achieve buy in and | | | | party although depending on the success it may have |
| commitment to the process from everyone, this is | | | | that atmosphere. It is a chance for some straight talk |
| key. If you don't your team will simply go through | | | | on what went wrong and more importantly how to |
| the motions and roll their collective eyes in project | | | | address that in the future. |
| meetings. To overcome this find their pain points in | | | | Everyone lines up for Post Mortems when things |
| how they work now and start with the areas of the | | | | went well but you can learn more from you failures |
| process that directly address these. | | | | than your successes. So if you had problems do not |
| -- Start Small: Start with a few areas that you feel | | | | miss this opportunity to address them when they are |
| are critical, again including pain points so your team | | | | still fresh in everyone's mind! |
| sees immediate benefits. It will be easier to add more | | | | Also, Teams need a sense of closure and this helps |
| process layers later when they see it as a benefit | | | | them do that as well as vent so you can clear the air |
| and not simply extra layers of bureaucracy. If you | | | | before you next project starts. Do not let anger and |
| start small your team will have a chance to get their | | | | infighting fester into your next project. |
| collective heads around this as well as see the | | | | -- Leave your ego at the door: No where are straight |
| benefits, making more maturation downstream easier. | | | | talk and the ability to provide and accept |
| Team Environment | | | | constructive criticism more crucial. This meeting |
| Each team has a different dynamic and will respond | | | | cannot be about egos, or CYA, it has to a frank |
| very differently to various aspects of what you are | | | | discussion about the mistakes made by everyone |
| trying to do. Too often, out of frustration with | | | | (we all make them) or areas in the process that |
| problems a new process is forced on a team. | | | | need to be improved. |
| This doesn't mean your team should dictate your | | | | Again to set the tone try leading off the meeting by |
| process, but as mentioned above your team's buy in | | | | the most senior person in the room discussing |
| to what you are doing is essential for your success. | | | | mistakes they made or things they learned. It really |
| Processes are never successfully steamrolled over a | | | | helps set the right tone and ease the tension. |
| team. So tread carefully, get your team involved in | | | | -- Take Notes, Then Action: This is the time to learn |
| discussions about what you are doing and why, it will | | | | and too often people discuss the issues then go off |
| pay dividends. | | | | and do nothing. This is the chance to take corrective |
| -- Roles and Responsibilities: Any process will have | | | | action to save you time and money on the next |
| roles defined for each individual and it is critical that | | | | project. So take copious notes and put them into |
| each person clearly understands the role they will be | | | | action while the iron is hot. |
| playing and feel they are comfortable in that role. | | | | Follow these steps in any process you adopt or any |
| Spend some time here and ask people if they are | | | | project you manage and you should find it really will |
| comfortable in their role, ask questions and listen! | | | | improve your chances at success. |