| The Rational Unified Process, Enterprise Unified | | | | used to show the progress of the project and its |
| Process, Agile Development Methodologies, | | | | various comments. Look for tools that allow the right |
| Unified Modeling Languages. They come in many | | | | level of detail (high level for management) and more |
| names, complexities and sizes but following one will | | | | detailed for individual departments and the project |
| help ensure success on your next project. | | | | manager themselves. For example Microsoft Project |
| This article is not a detailed overview of a formal | | | | for example is an excellent tool for managing very |
| process. Instead it provides an overview of the most | | | | strict rules driven projects. However many projects |
| critical components common to each, as well as | | | | are exception driven, making strict project |
| some tips on successfully deploying them. Although | | | | management tools difficult to use in a fluid changing |
| many process descriptions do an excellent job of | | | | environment. A great alternative is scheduling calendar |
| breaking down the various components of the | | | | software like The Calendar Planner which provides |
| process they rarely cover areas like how this affects | | | | the ability to manage various levels of detail in an |
| your team, how much process to use or offer | | | | easy to use calendar format. Allowing project status |
| practical advice on issues encountered in the real | | | | to be easily communicated among the team. |
| world when trying to deploy one. | | | | Scope |
| It can be very helpful as a beginner's introduction to | | | | Next to the Team environment this is probably the |
| process and can help you more easily grasp some of | | | | most critical aspect of any project. You absolutely |
| the concepts you will be introduced to. For the more | | | | must focus on clearly defining scope at the earliest |
| experienced process guru it should have some helpful | | | | stages of development. The biggest mistake is |
| tips on smoothing over some of the rough edges we | | | | usually trying to do too much on too short a |
| all deal with from time to time. | | | | schedule or budget or defining the scope and then |
| The information here is based on experiences and | | | | not adhering to it. This frustrates developers and |
| lessons learned in over 15 years of developing and | | | | ultimately throws the project into chaos. |
| managing over 100 complex project releases. | | | | - Be realistic. Everyone wants everything right now, |
| Following these fundamentals will improve your | | | | especially Sales and Marketing. Ask tough questions |
| chances of success in any process you adopt and | | | | early of these departments about what features |
| provide a solid foundation for maturing it. | | | | your customers MUST have versus what they |
| What's a Process and why do I need one? | | | | WANT to have. Sometimes you will find marketers |
| Regardless of what business we are in, software, | | | | have made promises to a single client and are trying |
| web site design or retail clothing, we all have a | | | | to save face when in the grand scheme the feature |
| process we follow to complete a given project. | | | | is not as important to the company's goals. Focus on |
| Sometimes it works and sometimes it does not, | | | | what you truly must do, let them know they can't |
| often with costly results. When we talk about | | | | have everything and force them to choose. Make |
| adopting a process we are talking about a more | | | | sure the company's goals are represented at all times |
| formal process. A process is essentially an integrated | | | | in requirements. This is where the Vision document |
| set of roles, methods and techniques to in part, help | | | | below comes in. |
| achieve the following: | | | | - Vision document. These may have various names |
| - Minimize risk. | | | | for different methodologies but a vision document is |
| - More accurately estimate your project schedule and | | | | essentially a high level overview of your project. |
| budget. | | | | Think of it as a mission statement for the project |
| - Detect problems early (upstream) instead of later | | | | itself. This is where the company can clearly define |
| (downstream) when they are much more expensive | | | | what the goals are for the project. Who the |
| to fix, if they can be fixed at all. | | | | stakeholders are and what the high level |
| - Better communication among team members | | | | requirements are. This will be your primary document |
| regarding project scope, requirements and status. | | | | for setting the scope of the project. Keep it HIGH |
| - More accurately track the progress of the project | | | | level, details can come elsewhere. Make sure the |
| and detect slippage early. | | | | requirements map to the goals and that as you |
| - Accomplish the project's goals as efficiently and | | | | move forward the work being done remains true to |
| cost effectively as possible. | | | | these goals and requirements. That can change but |
| Formal processes are often created and refined over | | | | only when the stakeholders agree and sign off on |
| years of trial and error to attempt to create an ideal | | | | the changes. |
| "recipe" for having an optimal chance at successfully | | | | - Don't increase scope without adjusting your |
| completing any project. While they were developed | | | | schedule and budget! Seems simple enough but |
| for and commonly used in Software Development, | | | | probably the single most common mistake. People |
| Aerospace and engineering, most of the core | | | | always try to add "small" things that involve "minimal |
| concepts are not specific to these or any industry | | | | effort". These add up and the impact is often not |
| and anyone can benefit from using them. | | | | addressed, which ultimately leads to a failure in |
| How much Process is enough? | | | | schedule and budget. The change board is your main |
| It is critical to the success of any process to | | | | defense against this, see change board below. |
| understand how much you initially need to bite off. | | | | Requirements |
| The risk of trying to do too much too soon with a | | | | Requirements in any project are tricky and many |
| process can be as risky as not doing anything at all, | | | | excellent books are dedicated to this subject alone. It |
| especially if you are a more agile company trying to | | | | is true that of the projects that fail most issues can |
| make the transition to being more process oriented. | | | | be traced back to requirements. Strange how this |
| Overloading your team with a new set of | | | | continues to be the case when requirements are the |
| responsibilities and methods they are not accustomed | | | | easiest and cheapest way to find and fix problems. |
| to or ready for can easily derail you. However if you | | | | - A problem will never be cheaper than it is right now. |
| don't start changing you will continue to have the | | | | When you review your requirements, you need to |
| same problems. Here are some tips of finding the | | | | really review them, don't just scan them. Think about |
| right balance. | | | | and try to visualize what they are saying. You will |
| - Risk Factor. What is the project's risk factor? | | | | often find problems are apparent at the surface. |
| Obviously making software for an artificial heart is | | | | Take the time to do thoughtful reviews and continue |
| much more risky than deploying the third generation | | | | to refine the requirements until everyone feels they |
| of a web site and the process, initially anyway, should | | | | are correct. Compare the expense of re-writing a |
| match the risk. The former would need extensive, | | | | sentence in a word processor to re-writing hundreds |
| redundant and exhaustive QA checks and balances | | | | of lines of code, re-testing and re-deploying and you'll |
| where the latter can be easily adjusted on the fly | | | | see these are the last chances you have at a cheap |
| after deployment with no loss of life. Be realistic | | | | fix. |
| about what your risks are, how expensive they will | | | | - Get your customers involved, early! Make sure |
| be to address downstream, and use this as a basis | | | | customers are involved in the earliest stages of |
| for deciding how much is required. No one knows | | | | requirements and keep them involved. Often a |
| your environment, project and team better than you, | | | | customer requests something and then developers |
| so use some common sense in deciding what feels | | | | disappear to figure it out. Big mistake! Come back to |
| right. | | | | your clients with explanations of how you envision |
| - How much can your team handle and what does it | | | | the feature and use mockups whenever possible so |
| need most? The impact on the team is often | | | | they can visualize it. You will find that making even a |
| overlooked. Any process is only as good as what | | | | simple drawing of something will not only allow the |
| your team can manage and regardless of the | | | | customer to grasp it more easily but you will quickly |
| ultimate benefits, initially it will cause additional effort | | | | spot problems you haven't considered. |
| in training and new tasks your team is not | | | | - QA starts at requirements. QA should be involved |
| accustomed to managing. To be successful you must | | | | at the beginning not just the end of the project as is |
| achieve buy in and commitment to the process from | | | | so often the case. Let them freely review Vision |
| everyone. If you don't your team will simply go | | | | documents and requirements. They will often view |
| through the motions and roll their collective eyes in | | | | potential issues that other departments may miss. |
| project meetings. To overcome this find their pain | | | | Change Boards |
| points in how they work now and start with the | | | | When done properly Change Boards can almost |
| areas of the process that directly address these. | | | | single-handedly manage even the most challenging |
| - Start Small. Start with a few areas that you feel | | | | projects. However if you don't have the correct |
| are critical, again including pain points so your team | | | | team environment in place as mentioned above, they |
| sees immediate benefits. It will be easier to add more | | | | will be ineffective at best and at worst will create |
| process layers later when they see it as a benefit | | | | more animosity. |
| and not simply extra layers of bureaucracy. Gaining | | | | - What it is. Very simply the change board is a |
| buy in is critical and if you start small your team will | | | | meeting where each of the key departments and |
| have a chance to get their collective heads around | | | | sometimes clients are represented and have a |
| this as well as see the benefits, making more | | | | chance to discuss the project from every angle. The |
| maturation downstream easier. | | | | idea is to make sure everyone is aware of the |
| Team and Environment | | | | status and is able to speak to the impact any change |
| One of the most commonly overlooked elements of | | | | in requirements or schedule will have on their |
| employing or maturing a process is the team itself. | | | | respective department. |
| Each team has a different dynamic and will respond | | | | - Who is there? Generally the list consists of the |
| very differently to various aspects of what you are | | | | following: Marketing, Sales, QA, Operations, |
| trying to do. Too often, out of frustration with | | | | Development, IT, Project management, Clients. |
| problems new process is forced on a team. This | | | | Essentially everyone who has a stake in or is |
| does not mean your team should dictate your | | | | affected by the project. Depending on the nature of |
| process, but as mentioned above your team's buy in | | | | the project Marketing or Sales will often represent |
| to what you are doing is essential for your success. I | | | | the client. The most important rule here is, if |
| have never seen a process successfully steamrolled | | | | someone is identified as a stakeholder in the project, |
| over a team. So tread carefully, get your team | | | | do not have a meeting without them. If they can't |
| involved in discussions about what you are doing and | | | | be there, reschedule. |
| why, it will pay dividends. | | | | - Where to start? A great way to start is usually to |
| - Roles and Responsibilities. Any process will have | | | | have everyone provide a brief update on what they |
| roles defined for each individual and it is critical that | | | | are doing regarding the project. This helps remove |
| each person clearly understands the role they will be | | | | the dark corners, often points out areas of |
| playing and feel they are comfortable in that role. | | | | disconnect and helps ease the tension of these |
| Spend some time here and ask people if they are | | | | sometimes contentious meetings by giving everyone |
| comfortable in their role, ask questions and listen! | | | | an easy topic to cover and maybe brag a bit to |
| Once your team is set, make sure they are | | | | start. |
| empowered to do what they need to do and make | | | | - Where to focus? The key issue in early change |
| sure everyone on the team is aware of who has a | | | | board meetings is scope. What is in and what is out? |
| gun and a badge. If your developers refuse to tell | | | | This will be a push and pull between what Sales and |
| your project manager the information they need you | | | | Marketing want and what those responsible for |
| will have a problem. If the project manager reacts by | | | | delivering can handle. After the scope settles down it |
| dropping soft milestones into your project plan you | | | | is about status. Are the Requirements still correct? |
| have a problem you won't even know about until it is | | | | Have priorities adjusted? Are we on target? Most |
| too late. So make sure roles are clearly defined for | | | | importantly each group is represented so if Marketing |
| everyone and that everyone knows who has power | | | | says: "I must have this", Development is there to |
| on the team. | | | | speak to the impact of this on the schedule, in real |
| - Full Disclosure. Enough cannot be said about this. | | | | time. Again it promotes visibility and keeps things |
| The purpose of any process is to address problems | | | | from being changed without everyone being able to |
| as early (cheaply) as possible and this can only be | | | | speak to the ramifications. It simultaneously controls |
| done with visibility at every stage to accurately | | | | and informs. |
| assess the status of the project. Developer egos, | | | | - How often? They are very useful so have them as |
| team infighting, and defensive posturing all create an | | | | often as you need. This will depend on the nature of |
| environment where no process can be effective. It is | | | | the project but every 1-2 weeks is best. Longer and |
| critical that team members are willing to admit | | | | you start to have too little communication and too |
| mistakes, call out problems and do so in a way that | | | | many potential areas for slippage, any more frequent |
| does not create a hostile environment. To do this | | | | and you eat into too much work time. |
| you must bring the parties together and openly | | | | - What not to do. Do not allow the meeting to |
| discuss this issue. Address the fact that issues are | | | | descend into arguments and finger pointing. The |
| brought up for the overall good of the project and | | | | change board is a tool that serves all departments. It |
| organization. Reward those who find fault in | | | | is essential it remains a place where people can talk |
| themselves and point out mistakes. Often the tension | | | | openly about issues. It is a place for reality, not spin. |
| can be cleared by starting with admitting your own | | | | This will be harder than it sounds at times but resist |
| mistakes first, others will follow, so lead by example | | | | the temptation to avoid them. There is no meeting |
| and you will see that you can create an open | | | | more important to the success of a project than |
| environment were people feel free to view mistakes | | | | these. |
| and even criticism constructively. | | | | Post Mortem |
| - Visibility. Similar to the above, visibility is all about | | | | The Post Mortem is a meeting to get together after |
| people feeling comfortable disclosing information to | | | | the project has completed. This is not a post release |
| the group. Developers will want to sit on code until | | | | party although depending on the success it may have |
| the last minute because they know it is not ready, | | | | that atmosphere. It is a chance for some straight talk |
| designers hate people seeing unfinished work. So | | | | on what went wrong and more importantly how to |
| understand why your developer or designer may be | | | | address that in the future. Everyone lines up for Post |
| twitching as their early work is paraded in front of a | | | | Mortems when things went well but you can learn |
| group and tread lightly at first with criticism until they | | | | more from you failures than your successes. So if |
| become more comfortable with this. Phrases like; | | | | you had a lot of problems don't miss this opportunity |
| "This is really great but how about..." are invaluable, | | | | to address them when they are still fresh in |
| use them! The fundamental goal of any good process | | | | everyone's mind! Also, Teams need a sense of |
| is catching issues as early in the process as possible. | | | | closure and this helps them do that as well as vent |
| So you must discuss this with your team and make | | | | so you can clear the air before you next project |
| sure everyone understands that this can only be | | | | starts. |
| done with full visibility on all aspects of the project. | | | | - Leave your ego at the door. No where are straight |
| The Proper Tools | | | | talk and the ability to provide and accept |
| You can't control what you can't measure. So make | | | | constructive criticism more critical. This meeting |
| sure you have the proper tools in place for both | | | | cannot be about egos, or CYA, it has to a frank |
| managing the process and being able to track and | | | | discussion about the mistakes made by everyone |
| communicate about your project. | | | | (we all make them) or areas in the process that |
| - Managing the Process. There are many excellent | | | | need to be improved. Again to set the tone try |
| tools available for managing requirements, QA, and | | | | leading off the meeting by the most senior person in |
| Development. As with the process itself make a call | | | | the room discussing mistakes they made or things |
| on how much you need before you dive in and start | | | | they learned. It really helps set the right tone and |
| buying. Shore up critical parts of the process. | | | | ease the tension. |
| Requirements management often gets the most | | | | - Take Notes, Then Action. This is the time to learn |
| attention but requirements can be easily managed in | | | | and too often people discuss the issues then go off |
| a word document while QA is often overlooked. A | | | | and do nothing. This is the chance to take corrective |
| solid database that allows QA to track features from | | | | action to save you time and money on the next |
| implementation to completion and any bugs that | | | | project. So take copious notes and put them into |
| result will be invaluable for QA and development and | | | | action while the iron is hot. |
| the project as a whole. | | | | Follow these steps in any process you adopt or any |
| - Tracking the Project. It is essential that your | | | | project you manage and you should find it really will |
| project manager is armed with a tool that can be | | | | improve your chances at success. |