The Kickoff Workshop

There are many ways to define the implementation requirements. As long as they produce a complete set of requirements that users can agree on within a minimum amount of time, they are all valid. For me, the best way to define implementation requirements is to start by holding a team workshop focused on the requirements right at the start of the project. A team workshop is effective because having all the stakeholders in the room makes for excellent brainstorming, so you are less likely to neglect important aspects of the requirements. Moreover, since the workshop includes immediate discussions of any areas of disagreement between the interested parties, the team can identify, confront, and resolve issues so you can get to a group consensus quickly. I call this workshop the kickoff workshop.

What Should It Cover?

The kickoff workshop is not a lightweight introduction to the implementation phase of the project, nor is it intended to create a detailed technical blueprint for the project. The workshop is meant to confirm measurable goals and a high-level project plan for the implementation. Specifically, the objectives of the workshop are to:

• Define measurable goals for the project.

• Identify gaps between the product and the desired result.

• Define a high-level project plan with schedule and owners .

• Identify large issues.

Let's examine each of them now.

Define Measurable Goals

Are you trying to increase revenue? Decrease costs? Increase customer satisfaction? Decrease lead turnaround time? The workshop is an opportunity not only to define the particular areas for improvement, but also to set measurable targets. Ideally , you should be able to measure your current level of performance and to forecast improvements from the baseline. If no baseline is available, define a target number that seems reasonable.

You must have all the stakeholders in the room to have a chance of defining goals for the project. The technical team members may have little say in setting the business objectives, and some of them don't have much exposure to the business side at all. Nevertheless it's important that everyone on the team understand the business goals since they will shape subsequent decisions. I like to start the workshop with the business goals since it gets the business owners emotionally engaged in the workshop (sometimes very much so!) and it sets the tone for the rest of the work.

You must end up with an agreed upon list of goals, not just discuss the goals at a general level or set tentative goals to be approved later. Since all the decision makers should be in the room you can press for firm decisions.

When you invite the business owners to the workshop, especially if the team is very large, tell them that the project goals will be set during the workshop so they can hold preliminary discussions with their teams if they wish and arrive at the workshop ready to commit to firm goals. The executive sponsor should attend at least the goal-setting portion of the workshop to reinforce and expedite the decision-making process.

Identify Product Gaps

Some teams like to start with a "blue sky" approach, where the business users are asked to model the ideal processes without thinking of the tool at all before the team attempts to reconcile the differences between the ideal processes and what the tool can do. I find that this approach takes a lot of time, since there may be many differences between the ideal process and the tool. It is also frustrating to the business users, who are asked to dream only to find out that their dreams cannot come true. Therefore, I prefer to start with a hands-on demo of the tool. I ask the business users to reflect on how they can use the tool to support the business processes and where changes will be required.

This particular part of the workshop can't get too far without having well-defined business processes in place. You need to include either a review of the current business processes if they are basically fine or a business process design session if the processes need work.

If you are creating processes from scratch, you can, in theory, follow the "blue-sky" method described above, and indeed some consultants recommend this approach as somehow more "pure" and likely to yield better efficiencies. I'm afraid that it often yields processes that require lots of customization work on the tool, hence causing delays and risks, while a more tool-centric approach is faster, cheaper, and safer. An experienced integrator should be able to facilitate the process definition phase of the workshop by suggesting common alternatives that can be implemented without too much trouble. The integrator may even go as far as starting with a quick demo of the tool to start on the right (low-customization) foot .

If large amounts of process definition work are required, it may be appropriate to dismiss most of the technical staffers from the workshop during that discussion since the value to them is small. However, all team members must be fully briefed on the outcome of the discussion.

It's very helpful to organize the process discussion around user roles, first defining what types of people (roles) will use the system and then what they will do with it. For instance, a telesales rep will perform certain tasks that are different from the tasks of a field rep, which are different from the tasks of the technical sales specialist. If you picked the super-users well all roles will be represented on the team so it will not be difficult to proceed.

The gap analysis should identify the critical changes and accommodations that are required to meet the business objectives defined earlier. The workshop leader (we'll come back to who this may be very soon) should gently question how each identified gap relates back to the objectives, especially if the team veers off into a mode of requiring extensive changes. As long as there is not a complete incompatibility between the tool and the process, it's easier, faster, and less risky to adapt the process to the tool rather than the other way round.

Especially if lots of process work is required, the executive sponsor should attend this portion of the workshop to guide the business users to reasonable compromises.

Define A High-Level Project Plan

No, I'm not crazy, at least not about the feasibility of creating a high-level plan during the workshop without having explored all the intricacies of the design. For starters, working from firm deadlines is a good discipline. That is, if you need a solution in six months, set a six-month goal and see what can and cannot be achieved within that timeframe, rather than building an ideal solution only to discover that it will take nine months. Second, with an experienced integrator and appropriate technical staff in the room, you should be able to make ballpark assessments of what is required for various implementation options (if not, the experience level in the room is insufficient). Third, with everyone in the room you can assign owners and get commitments that are witnessed by all, saving a lot of time compared to a more traditional process.

Attendees should understand that they will be expected to make commitments to a high-level project plan during the workshop so they can prepare appropriately prior to it and either consult with or bring along critical individuals as needed.

Kickoff workshops often identify functionality that cannot or should not be implemented in the first phase of the rollout. Start a list of such features right away, identifying specific phases whenever possible, so the business users can have an overview of when they will be rolled out.

Identify Large Issues

The last objective of the workshop is to catch large implementation issues, and ideally to resolve them. The point is not to find each and every issue that may exist, as that's not possible, but rather to identify significant challenges. For instance: the tool was purchased to serve 300 users, but another 120 also need to use it; the deployment environment was planned to reside in the main data center, but the data center has no room available; the target deployment date conflicts with the sales meeting; the tool is supposed to be integrated with the back-end accounting system but that system may change soon; etc.

Any large issue identified in the workshop and left without a resolution by the end of it must be assigned an owner who is responsible for resolving it and an early resolution target so it doesn't cause problems down the line. From the set of examples above, the deployment date can be adjusted not to conflict with the sales meeting right in the workshop. On the other hand, the issue of the changing accounting system will need to be settled with the owner of that system soon after the workshop and before integration work starts, probably by the IT owner on the team.

The end result and deliverable for the workshop is a high-level project plan that includes the desired, measurable goals for the project; high-level specifications for the customization, which will be fleshed out later; ownership of the various phases and aspects of the project; and a high-level schedule. For smaller projects, the deliverable can be the full specification set for the implementation.

To meet the objectives and create the deliverable, a typical agenda includes the following:

• An introduction to the project and to the workshop, including introductions of all the team members, a review of the schedule, logistics, and ground rules, led by the workshop leader.

• A session to define the goals for the project , introduced by the executive sponsor.

• A review of the business processes covered by the project, as well as critical business processes around it. For instance, for a sales automation project it would be useful to understand how orders are recorded and customers billed, even if it's done outside the system being deployed, since integration work may be required and in any case the order processing may require specific information from the system under construction. The project should not be allowed to go forward without a clear, agreed upon understanding of the underlying business processes.

• A product demo and high-level gap analysis . That is, the basic flow of the product should be demonstrated so that technical and business staffers can identify where the product supports the business processes and where it needs to be changed or added to. This is not the time to worry about how the changes will be made, although it's very helpful if the integrator can gently challenge requirements that are known to be difficult and suggest easier alternatives.

  This is the largest chunk of the workshop if business processes are reviewed rather than defined there and could take several days for complex projects. We'll come back to recommended workshop lengths a little later.

• Finally, a review of the decisions and requirements defined in the workshop and high-level plans for future steps. The review is more than a simple summary and includes a formal commitment from each team member to the decisions that were made during the workshop. The value of the workshop derives in great part from the strength of the commitments that are made in it and not just what the commitments contain.

Who Should Be There?

Everyone! All project team members should participate in the workshop, including the business owners, the IT owner, the super-users, the technical staff, and of course the project manager. The executive sponsor should attend whenever possible, and in any case should introduce the session to reinforce the business goals and to inspire fruitful participation from all team members. If there is any possibility that political issues may mar the workshop, the executive sponsor should plan to attend it in its entirety.

One of the functions of the kickoff workshop is to define what additional talent may be required for the project, so it's possible and even likely that individuals who did not participate in the kickoff workshop will become part of the team later on. For instance, each and every programmer who will touch the tool doesn't participate in the workshop. Each and every IT function does not participate in the workshop. But the lead programmer (usually from the integrator) and the IT owner should attend and ensure that appropriate resources attend the workshop or are on call for any questions, especially the database administrator and the individuals responsible for any system that will be interfaced with the CRM tool.

How Long Should It Be?

The length of the workshop is determined by the scope and complexity of the project. That being said, even a very simple project will require several hours to ensure that all aspects of the implementation are examined, while the law of diminishing returns dictates that the workshop not exceed a week even for a very large project. A good rule of thumb would be as follows :

• One day for simple projects, that is, point solutions for one business function with a small user base, and no more than a couple of integrations. Add half a day to a day to address process definition if processes are informal or are known to require changes.

• Two to three days for medium-complexity projects, that is, projects that target one or two business functions, for a moderately large user base, and with only a few integrations. Add another day to address significant process changes.

• Four to five days for high-complexity projects that address multiple business functions with lots of functionality, users, and integrations. It's simply not practical to keep the participants engaged and contributing for longer periods of time, so for the larger projects the best approach is to target only a high-level definition of the project for the kickoff, with follow-up work from various subgroups taking place afterwards to get to the level of detail required. Another feature of complex projects is that it's possible, necessary, and fruitful to run parallel sessions for each business function on some of the topics so even though you have only 4-5 days you should be able to multitask for 2-3 of those days.

Some groups work faster than others, and some groups work more harmoniously than others, which also makes for faster results, but it's very unlikely you will be able to compress the timelines significantly. Plan for a reasonable timeframe and reward fast-working groups with an early dismissal.

Although it's theoretically possible to hold the kickoff workshop in short segments spread over days or weeks, it's much more efficient to schedule it in one go. Much momentum is built by scheduling a single session and it's easier to get everyone together in one place if team members need to travel to the session.

Since many individuals on the team are involved in customer- facing operations, schedule breaks during the workshop so they can take care of urgent issues. It's best to schedule two or three longer breaks during the day rather than sprinkling short breaks here and there. Frequent short breaks are never long enough to accomplish anything significant and create challenges when trying to regroup. The breaks can be used profitably by the workshop leader and other key individuals to regroup, summarize, and get ready for the next session.

Where Should It Be Held?

Standard wisdom is that kickoff workshops should be held in an offsite location to ensure that participants don't wander off to take care of other business. I find that offsite locations can be a hassle for participants to get to (and you want happy participants in the kickoff workshop, trust me on this!). More importantly, they make it difficult to include unplanned participants when needed, which is not unusual for the more obscure IT specialties. Sure, you can call people by phone, but since kickoff workshops are usually heavy on pictures and notes scattered about boards and flipchart paper, a phone conversation is usually not enough.

The decision between onsite and offsite mainly comes down to discipline. The issue is not so much the physical location but your ability to maintain the participants' attention on the topics at hand; although you could herd the bodies it's really a matter of herding the minds. If you are concerned that an onsite meeting will be poorly attended, by all means go offsite, but try to stay close enough to be able to include last-minute participants. Anticipate that you will encounter other problems that can crop up in an undisciplined environment.

The kickoff workshop is the one meeting that should be held with all the participants in the same room. Brainstorming sessions and complex decisions are best made with lots of notes and interactions, which no conference call can simulate. It's quite possible to use conference calls to discuss status during the project, but not for the kickoff.

Especially for multi-day workshops, select a location that offers a comfortable environment with room to move around, plenty of note-taking equipment (flipcharts work best since you can post sheets around the rooms and even take them back to the office to extract notes) and a number of smaller breakout rooms. Sometimes it's difficult to find a suitable environment onsite, and that's a good reason to seek an offsite venue . Try to find a place that is secure overnight so you can leave all the notes in place from day to day. Also, since you will need to do a demo of the product, and perhaps to access some of the in-house systems to check technical facts, an appropriate computer system with a dialup capability and a projection system is a must and is yet another reason why onsite venues are desirable.

Finally, kickoff workshops can get intense . Being able to indulge in recreational activities is a plus, even if it's nothing more than a walk in a park.

Who Should Drive It?

It seems obvious that the project manager should drive the kickoff workshop, but it's sometimes the case that someone else would be better at it. Let's start by reviewing the characteristics of a good workshop leader.

• Understanding of the business issues . The workshop leader doesn't need to be intimately familiar with the way the organization does business (and actually it's often better if the workshop leader is somewhat detached from the issues) but the leader should be conversant with the business concepts and terminology and the technical issues at hand. The goal here is to be credible with all members of the team.

• Disciplined but flexible . The leader needs to make sure all topics get attended to within the time allotted, but without making the participants feel trapped into an inflexible agenda. Diverting from the stated schedule or goals is just fine if circumstances change, and a rigid approach is counterproductive.

• Not a key decision-maker . The workshop leader should not get dragged into the minutiae of the meeting, and should certainly not take sides in any particular discussion. It's usually best not to place a key business owner in that position for fear of squashing the debate.

• A bit of a cheerleader . Even short workshops have low points. The workshop leader should be able to sense when the participants are getting discouraged or frustrated and to offer appropriate comfort . A sense of humor is also very helpful.

If the project manager doesn't have the appropriate skills to lead the workshop, pick someone else from the team who does. The project manager, the workshop leader if it's not the project leader, and the other key players should carefully plan the workshop ahead of time to ensure that the attendees, agenda, and location are conducive to an effective meeting.

Managing A Successful Workshop

Breakout Sessions

Much of the power of the workshop lies in having all the players exchanging ideas and creating agreements and commitments. However, there are good reasons to also include breakout sessions that focus on specific issues. Some of the topics are of marginal interest to some of the participants; a brief exposure can achieve the desired awareness and commitment while avoiding a long, boring, interest-sapping session.

Therefore, the typical agenda includes a mix of group and breakout sessions, at least for larger projects. Kickoff workshops for simple projects are usually short enough that breakout sessions are more trouble than they are worth (and, to be sure, with a small team breakout sessions don't make much sense). For longer workshops, breakout sessions are useful for two topics.

• Defining business processes . If all that's needed is a review of the existing processes and a small amount of tuning, then a group session is sufficient. But if you need a lengthy session it can be conducted with only the business users in attendance since the technical staffers would have little input anyway. Regardless of whether you have a breakout session to define process, hold a review of the processes for the entire team. The technical staffers should be exposed to the business processes since they will need to integrate those processes into the technical deliverable.

• Performing the gap analysis . Unless you have a small group, start the gap analysis with a reasonably short group session and then break out into subgroups to get to the next level of detail. Ask the business staffers to focus on process gaps while the technical staffers focus on technical issues. Organize the business staffers by business functions so sales employees look at sales issues, marketing employees look at marketing issues, etc., if multiple functions are represented. If you prefer, you can ask the managers to look at management processes while the support-users concentrate on individual contributors' issues. Meanwhile, the technical staffers should work in specialty groups so the database folks look at data model issues, the network people talk about the network issues, etc.

  Headcount permitting, it's very useful to do some mixing and matching for the gap analysis breakout sessions. For instance, invite some service folks and some technical folks to attend the sales gap analysis. They may not be able to provide much information but they should be able to contribute interesting questions since they are free from the idea that "we've always done things that way." Even if it's not possible to assign outsiders to the breakout sessions, encourage each subgroup to pull from other groups when they feel it would be beneficial to add cross-functional expertise.

While breakout sessions are useful for some topics, others should be strictly handled through group sessions because requiring the entire team to participate makes for a better informed and more committed team. For instance, defining the business goals can be viewed as the exclusive domain of the business users and indeed it is, to a great extent. But I would definitely hold it as a group session to ensure that the technical staff is fully briefed on this foundation topic.

Finally, even those topics that lend themselves to breakout sessions must be concluded with a group presentation where each team presents its work and others are encouraged to ask questions. Such group presentations facilitate cross-pollination and buy-in from the entire team. If the breakout sessions are particularly long, I also like to punctuate them with group sessions every few hours to exchange updates. It's good for teamwork and it's a good incentive for each team to avoid long and fruitless discussions in breakout sessions since they have a short- term goal of preparing a meaningful update.

Records

The deliverable for the end of the workshop is a high-level project plan, including the objectives for the project, a high-level description of the customizations and integrations required, and an overall project plan including schedule and owner. Moreover, that project plan should be approved by all the stakeholders, who should be in the room if your project team is properly designed. Since you are going both for content and for decisions, I strongly suggest eschewing traditional minutes and concentrating instead on building the project plan document right during the workshop.

At least for larger meetings, it's best to designate an individual other than the workshop leader to do the recording so the leader can concentrate on the management task. (If the project manager is not leading the workshop, that individual is a good candidate.) Capture relevant notes and pictures drawn on boards and flipcharts.

Make time every day or every half-day to review the draft plan and to confirm the team's approval. Approval should not be difficult to get since you are recording facts and decisions that attendees have agreed to already.

Note that the project manager must keep detailed records on all agreements and decisions made at any time during the project. This is not a trivial requirement since CRM projects are long and complex. Some attention to how the records are kept and how they are made accessible to the team members is useful from the start of the project.