Change Management in the Project Lifecycle: Test Phase

By now, your Change Management team should be fully staffed and ready to put in some serious hours.  The test phase is when the project team verifies that the system they built works the way it was designed.  Although the Change Management team is sometimes left out of testing activities, it is extremely beneficial for your team to participate in test.  This is especially true for training developers and deliverers, as this is the perfect opportunity for them to get extensive, hands-on interaction with the new system.

Training

The majority of your team's time during the test phase will likely be dedicated to training development.  Now that the system is built, your training developers can get into the system to figure out how it works and start to create training documentation.  If this is a packaged system, experienced developers may only need to figure out how the system was customized.  In the case of custom systems, developers may end up needing to learn the system from scratch.

I could write dozens of posts on training alone, but for now, here are just a few of my top tips for training development during the test phase:

• Functional team/SME access: No matter how experienced your developers are, they will have questions about the system.  Ensure they have access to members of the functional team, as well as Subject Matter Experts.
• Document, Document, Document: It is always easier to cut content from training than it is to try to add content that was missed.  Stress to your developers the importance of thorough training documentation.
• Standards: If you have more than one training developer, make sure to put in place documentation standards prior to the start of training development.  Then make sure all of the developers understand the standards.  This will help ensure consistency of training materials across all developers.
• Sign-off: Put in place a sign-off process.  Involve members of the team and the business.  No matter how busy people say they are, enforce the sign-off process.  Nothing will explode in your face faster than training materials that are delivered to the business without proper sign-off.

Communications

Now that you are getting closer to implementation, it's time to begin communicating details.  People will start to be very interested in information about training, especially when and how much.  They will also want to know when they will be expected to begin using the new system.  Everyone is busy, and it's best to give them plenty of time to begin planning their schedules around things like training delivery schedules and go-live activities.

This is also a critical time for keeping your ear to the ground.  As people hear more about the new system, complaints are likely to begin popping up.  This department doesn't like the screen layout.  That department feels like they're losing functionality that was provided by the old system.  Another team heard that the system won't go live on time.  Rumors will be swirling and you can only address them if you are aware of them.  Work your network, and remember: It's always better to address issues and concerns head-on.  If you don't tell the project's story, someone else will...and you might not like the story they tell.

Super User Training

The test phase is an excellent time to begin hands-on training with your Super Users.  Three easy ways to start their training:

1. Involve them in test activities.  This will give them lots of hands-on experience with the system, as well as the opportunity to ask questions of the functional teams.
2. Involve them in training development.  Super Users can provide valuable insight during the training development process about which activities are likely to be the most difficult for their peers.  This can help you focus the training materials on the most important topics.
3. Involve them in training pilots.  You will likely want to pilot your training materials with a small group before rolling them out to the entire organization.  Using the Super Users as your pilot group not only gives you a ready-made pilot group, but it also gives the Super Users an early round of training.

Keep in mind that the type of training you put your Super Users through will be highly dependent on their role in training and implementation.

Day-in-the-Life

Hopefully, by now, you have run a number of system demonstrations targeted at different audiences across the organization.  What most people really want to know, though, is, "How will this change impact the way I do my day-to-day job?"  Running special Day-in-the-Life demonstrations gives you the opportunity to address this question.

A Day-in-the-Life demo focuses on how a specific person/job/department will use the new system as they do their normal activities throughout the day.  It looks at:

• Where information comes from
• Where information is sent
• New tools and processes
• Integration with existing systems
• Specific activities required to perform a specific job/role

A word of warning.  If, during the test phase, the team discovers major bugs in the system, it is best to hold off on doing Day-in-the-Life presentations until the bugs are resolved.

Change Discussion Guides

Information that comes from a trusted and respected colleague is always received better than information that comes from an outside consultant.  This is why Change Discussion Guides are a great tool.  Change Discussion Guides are information packets that are given to managers.  The managers then use this information to hold discussions with their direct reports and teams to help them understand the changes that will come as a result of the new system.  Information you may want to include in a Change Discussion Guide includes:

• How jobs/roles will change
• Aspects of a person's job that will become easier or harder
• Required and optional training
• Implementation timeline
• Where to get help with the new system
• Frequently asked questions
• Department-specific changes

As part of the Change Discussion Guide, make sure to build in time to review the guide and the information in it with the managers, so that they are fully prepared to meet with their people.

Go-live Preparation

Now is the time to start making a Go-live plan.  Most of the plan will revolve around communications.  What information do you need to send out?  When does it need to be sent?  Who is the best person to do the communicating?

I would also recommend that you have a back-up plan.  The back-up plan should focus on what communications will need to be sent if the system does not go live as scheduled.  I know it sounds like a very negative step to take, but sometimes cutovers do not go as expected, and it's important to have a plan in place to address this scenario.

Only two phases left!  You're almost there.

Let me know: Have you ever served as a Super User?  What activities were most effective at keeping you engaged in the project?

Change Management in the Project Lifecycle: Build Phase

The Build Phase is when the new system comes to life.  Packaged systems are customized to meet the client's requirements and reflect the agreed-to design.  Custom systems are built from the ground up and can be viewed as a functioning program for the first time.

This is when the project really starts to get busy for Change Management.  Up until now, you may have been feeling relaxed.  You may even have felt guilty that you weren't working long hours like the rest of the team.  Never fear...you are about to ramp up.

Communications
You should already be in a groove when it comes to communicating with Sponsors, project team members, and Super Users/Change Agents.  Now is when you can begin end-user communications.  I'll write another post where I go into more detail about how to generate a detailed end-user communication plan, but for now, here are suggestions about topics you might want to communicate:

• The Final Design: Design phase is complete.  This is an excellent time to let people know what the new system will be capable of doing and what it will look like.  I like to have two sets of messages here.  First, I start with a high-level overview of the system design that explains how it will be used in an integrated fashion by the entire organization.  Second, I follow up with department-specific communications that go into more detail about how the part of the system each group will use has been designed.  Don't be afraid to name drop.  If someone from the department helped design the system, mention that so that future end-users will feel comfortable that their needs were represented and the system wasn't designed in a vacuum by the project team.
• Project Timeline: Start communicating a high-level project timeline.  I don't usually go into much detail at this point, because time lines change, but it doesn't hurt to let people know that training will be rolled out in Q2 and the Go-live will occur in Q3.  This helps to 1) re-assure end users that you haven't forgotten about important activities such as training, 2) allows them to understand when changes will occur, and 3) reduces the sense of panic about an unknown future that develops when people don't have a general time frame for major changes.
• Benefits: The project should have a list of benefits that the new system will bring to the organization.  Begin communicating these.  Once again, you can have two sets of messages: one set for the organization as a whole, and one set that is department-specific.  A word of warning: If there are no real benefits to the system implementation (and I've seen projects where this was the case), don't try to make them up.  People can see through fluffy corporate jargon in seconds, and will read any future communications you send with a skeptical filter.
• Bonus: If you have screen shots (or even real demos) of the system that you can share, start doing it!  People love pictures and demonstrations and they will get you a lot farther in building an understanding of the change than any e-mail or list of bullet points ever could.  Just make sure that the screen shots are unlikely to change, and that demos actually work before sending them out.

Training
Now that the system is designed, you are able to create the training analysis.  This is where you determine who needs to be trained on what parts of the system, when this training needs to occur, and how you will deliver the training.  This is a tedious and time-intensive activity, but it is crucial.  Not only will it allow you to create a detailed training curriculum, but it will also help you to determine the plan for creating all of the training, including how many training developers and deliverers you will need.

I strongly recommend that you get input from the functional teams, subject matter experts, and Super Users.

This is also a good time to have a meeting with the client's HR or training department.  Ask them about past training they've implemented.  What worked?  What didn't?  Are there certain unique aspects about the organization that could impact the timing or method of delivery?  Remember - things like shift work, unions, hourly employees, and location can greatly impact your training plan.

Change Impact Assessment (CIA)
There are many variations on the Change Impact Assessment.  The one I do has three components: people, process, and technology.  This is designed to help the project, the Change team, and the organization's leadership understand how the new system will affect the organization: the good, the bad, and the ugly.  You may find that the change will bring benefits to the organization across the board.  Or you may find that one department is gaining a lot of benefits from the change, while another department is losing something that they consider vital to their work.  Regardless of the results, it is important not to sugar coat the outcome.  A frank understanding and discussion of the impact of the change will allow you to capitalize on the positive and address the negative.

There is some disagreement over the best time to conduct the CIA.  Many projects will conduct it much earlier in the project.  My experience, though, is that until the design is complete, people don't understand the new system well enough to give good insight into how it will be different from their current way of doing things.

• People: In this portion of the CIA, you focus on the impact to people.  Will their day-to-day responsibilities change?  Will you need more or less people to do the same tasks?  Will they need to learn new skills?  Are they open to change?
• Process: New systems often lead to new or change business processes.  Is the organization moving from manual to automated processes?  Are steps being added or removed?  Will the roles involved in a process change?  Will the length of time required to complete a process be more or less?  Are new safeguards (e.g., authorizations, audit trails, etc.) being added to the process?
• Technology: This is a basic nuts-and-bolts comparison of existing technology against the new technology.  In an organization where different departments or business units were allowed to select their own technology, you may find very different impacts.  Especially in organizations where there are a lot of home-grown systems that were specifically designed for a department's individual needs, you are likely to find that people consider the new technology a step backward.

Organization Design
Now is a good time to start working with Human Resources to understand if there is an organization design component that is required as a result of the new technology.  If there are new skills that are required, job descriptions, compensation structures, and responsibilities may need to change.  Entire teams and departments and departments may need to be re-designed if the roles, responsibilities, and processes are changing drastically.  You may also find that positions need to be added or eliminated based on the new system's ability to increase or decrease workload.  Even if HR comes back and says they don't want to make any changes until they've seen the system in action for a few months (which is a response I've heard often), it's good to at least begin thinking about how the organization may need to adjust in response to the coming changes.


Let me know: How often is Organization Design part of the projects you work on?

Change Management in the Project Lifecycle: Design Phase

The Design Phase is where things really start to get fun.  As the functional teams work with end users to determine how to translate the requirements gathered during the Analyze Phase into useable system functionality, it's time for the Change Management team to ramp up.  If you've been a team of one up until now, Design Phase is an excellent time to bring on another team member.

Practical Design Phase Activities

Once again, the activities in this phase can be broken down by which team you partner with.  This time around, we'll add another team: Human Resources.

Activities Conducted by Change Management

Executive Change Readiness Assessment (ECRA):  The ECRA is designed for top-level Executives.  This will typically include your Sponsors, the Directors and/or Vice Presidents of impacted business units, and, depending on the organization, C-level Executives.  The focus of this assessment isn't whether the Executives are ready to change, but whether they are ready to direct and support the change.  You should plan on conducting this assessment multiple times throughout the project, depending on the project's length.  Use the first assessment during the Design Phase as a baseline against which to measure future iterations.

Change Readiness Assessment (CRA):  The CRA is designed for the future system end users.  Unlike the ECRA, the CRA does focus on whether end users are ready to adopt the change.  The assessment asks end users whether they feel they are receiving enough communications, adequate training, and sufficient management support.  Once again, plan on conducting the assessment multiple times during the project.  And remember that this first one is a baseline...your results will not be good, and that is to be expected.  You haven't rolled out any training, yet.  How can they give it high marks?

Super User/Change Agent Network:  There are many different names for this type of network, and many different uses.  Essentially, it is a group of future end users who are not full-time members of the project, but who are asked to participate in project activities.  Their role may be to act as Super Users who know the system better than your average end user and are expected to eventually serve as trainers and front-line support.  They may simply be Change Agents who are asked to vocally support the change among their peers and help others embrace the new way of doing things.  Or they may be some combination of the two.  Whatever their role, they are an integral part of helping the change be adopted throughout the organization, and should be selected with care.  Once you've created the network, manage them with care, show them lots of love, and you will see great returns on your investment.

Communications:  There still isn't a lot to communicate to the general end user population at this point, but you should be actively communicating with your Change Agent Network and Sponsors.

Training: The functional teams will likely be holding a large number of design workshops during this phase.  If at all possible, you should have your training developers attend as many of these workshops as possible.  This will help them develop a solid understanding of the system design that will help them build the training in future phases.

Partnering with the Functional Teams: If you have more than one person on the Change Management team, I recommend assigning each person to one or more functional teams.  This does two things.  First, this provides one point of contact for each functional team.  This way, they don't need to try to guess who on the Change team to contact when they have questions.  It also reduces the number of e-mails and phone calls the Change lead has to deal with each day.  Second, it helps ensure at least one person on the Change team will have a deep understanding of each functional area, which will come in very handy for developing communications and training.

Design Feedback Workshops: If the functional teams haven't planned these on their own, recommend they be added to the plan.  If they have planned these, volunteer to help.  Design Feedback Workshops are conducted with the end users who provided input into the system design.  Once the functional teams have incorporated these design suggestions into the system, hold a workshop where you show the completed design to the end users.  This gives them an opportunity to tell the team if the design meets their expectations.  You may also find that once they see the design, it helps them better understand the system and helps them identify new or better refined design points.


Partnering with Project Management
Phase Kick-off/Lessons Learned: In the Analyze Phase, I talked about the need for a project kick-off.  As the project continues, it's important to conduct phase kick-offs, as well.  These help ensure that everyone on the project team understands the timeline, objectives, and activities for the upcoming phase.  The kick-off is also a good time to conduct a lessons learned session.  For more details on connecting an effective lessons learned session, read this earlier post.

Sponsorship:  How involved Project Management wants to be in Sponsorship is something you'll need to work out on each project.  I have typically found, however, that working with the Sponsors tends to be a joint effort.  If your Sponsors haven't been overly involved up to this point, now is the time to help them become active.  Work with the Sponsors to determine how much direction they want/need, their expectations of their role as a Sponsor, and the project's expectations of their role.  It is important for them to understand that their commitment to providing active, visible sponsorship directly impacts the success of the project.

Partnering with Human Resources: Throughout the project, there will be activities that are best completed in partnership with Human Resources (HR).  These are activities that impact people's job descriptions, compensation, or team structures.  If you are ever in doubt, it's a wise idea to find out who is the project's HR representative and have a quick chat with them.

Rewards and Recognition:  If there are people on the project team who are not consultants, chances are that being on the project is requiring them to learn new skills, work longer hours, and take on additional responsibilities.  These are things that should be recognized and rewarded.  Work with HR to determine how the project team can do this within the appropriate guidelines of the organization.  I've seen programs as simple as a Thank You Box, and as complex as a new bonus structure.  Whichever path you take, make sure that you are rewarding behaviors you want to perpetuate, and providing rewards that are meaningful to the recipients and in-line with company policy.


The Design Phase is a busy one, but it's also very satisfying.  Don't forget to evaluate how successful the Change program is in achieving its goals, and don't be afraid to tweak the plan as you go to improve your results.

Let me know:  How many people have you typically had on the Change Management team during the Design Phase?

Change Management in the Project Lifecycle: Analyze Phase

You've made your plan, now it's time to put it in motion.  During this phase, your activities will fall into three different categories:

1. Activities you do purely as a Change Management team
2. Activities you do in partnership with the Project Management team
3. Activities you do in partnership with the Functional teams

There may be some debate about which team actually owns each of these activities.  If so, I suggest you hash it out and develop a RACI.  This is a chart that clearly identifies for each activity who is Responsible, Accountable, Consulted, and Informed.  It will save you a lot of headache throughout the project.

Practical Activities in the Analyze Phase

• Change Management Activities: The Change Management Activities you complete in this phase set the stage for future phases.
• Project Branding - Branding your project makes it instantly recognizable to people in your organization.  This can include a catchy project name, logo, and tag line.  I've even been on projects that have colors, mascots, and songs.  Be as creative as you want...just make sure it fits with your company's culture.
• Communications Analysis - The Communications Analysis looks at what messages you need to send, who should send them, who should receive them, and what vehicles are currently available.  It also takes into account message timing, frequency, and high-level content.  Once you have this information, you can determine where there are gaps and work to fill them.
• Initial Training Analysis  - Training typically runs half a phase behind the project, which means that you won't begin your initial training analysis until the Analyze Phase is half-way over.  At this point you are simply determining basic facts, such as the number of people to be trained, their geographic location, and a rough feel for the amount and type of training that will be needed.
• Partner with Project Management: These activities address the internal workings of the project team. I have seen them completed by the Project Management team on some projects and by the Change Management team on others.  I have found, however, that you get the best results when the two teams collaborate.
• Project Governance and Escalation - Who has the right to make project decisions?  Who will weigh in on these decisions?  If the people assigned to make the decision are unwilling or unable to decide, to whom is the decision escalated?  Who is able to remove roadblocks and help the team overcome obstacles?  These are the types of questions that are answered as part of developing the Project Governance and Escalation plan.
• Project Standards - Most projects are made up of people from different departments, experience levels, backgrounds, and even companies.  To ensure that they project a united and professional image to the organization, you should set project standards.  These can include PowerPoint and Word templates, guidelines on how to run meetings, and processes for getting external communications approved.
• Project Kick-off - It is never safe to assume that everyone on the project is on the same page.  Use the project kick-off to acquaint everyone with the project's goals, team structure, timeline, near-term activities, and anything else for which you want them to have a shared understanding.
• Partner with the Functional Teams: The functional teams are the "business" teams.  They are the ones gathering business requirements, developing business processes, and generally working to ensure the new product meets the business' needs.  
• Requirements Gathering - Gathering business requirements often involves creating presentations and conducting workshops.  The functional teams are often happy to have the Change team lend a hand polishing presentations and facilitating workshops.  Facilitating the workshops, especially, frees up the functional team's resources to focus on what the end users are trying to explain about their business needs.
• External Communications - Working in partnership with the functional teams when they need to send communications outside of the project team helps to ensure consistent messages are being sent to the organization.  It also allows the Change team to understand which audiences have received which messages, reducing the likelihood of redundant communications.

Let me know: How have you effectively collaborated with the other project teams during the Analyze Phase?

Change Management in the Project Lifecycle: Plan Phase

On to the Plan Phase.  This phase can be slightly frustrating for Change Managers, because so many of the activities we do are dependent on the activities conducted by the other project teams.  It's very difficult to plan when you'll conduct training if you don't know when the system will be built and stable.  Because of this, I typically recommend that Change Managers add their team's activities to the plan after the technical and functional teams.

There's also an ongoing debate as to how much of the Change Management plan should be included in the overall work plan.  I've met a number of Project Managers who don't want to see every single planned communication cluttering up their work plan.  

Here's my recommendation.  It's good to have as much of the Change plan in the overall project plan as possible, so that the integration between the teams is clearly visible.  The functional and technical teams should understand how changes and delays in their activities impact Change Management activities.  If that's not possible, however, the project work plan should at a minimum include Change Management milestones and the activities that are most impacted by other teams, such as training development.

If the Project Manager doesn't want any Change activities in the overall project work plan, you have bigger problems on your hands, and I suggest you set up a meeting immediately to discuss.

But enough of the introduction.  It's time to discuss:

Practical Steps to Develop a Change Management Plan

Training:  Training is perhaps the most critical Change activity to plan well.  You may not know exactly how many training courses you're going to develop or how many people you're going to train, but here are a few guidelines to get you started.  (A quick disclaimer that will apply to the rest of the post: Work plans are living documents.  You will constantly need to go back to update and refine your plan as you get new information. )

• Build some time for training into the Analyze, Design, and Build phases.  Training developers who spend some time in business requirement meetings, system demonstrations, and testing will be better prepared to develop training...and will reduce the amount of time required from Business Analysts.
• The industry standard for the time required to develop training is this: It takes 40 hours of development time to create 1 hour of classroom training.  It takes 200 hours of development time to create 1 hour of fully interactive computer-based training.  Everything else falls somewhere in between.
• The level of expertise of the people developing training impacts the amount of time they require for development.  Take this into consideration.
• During training development, Business Analysts should expect to devote 10% of their time to working with the training team.  This is extremely important and often overlooked.
• For training delivery, assume that for the first time someone delivers a course, they will need 1 hour of preparation time for every 1 hour of training they are delivering.
• During training delivery, the technical team needs to devote a portion of their time to addressing technical issues and performing activities such as training instance refreshes.
• Training doesn't end at Go-live.  There will be people who need to be trained in the 1 - 4 weeks after the system is implemented.  Plan to have one or two team members stay around to deliver this training.

Communications:  Although you might not know exactly what communications you need to send each week throughout the project, assume that you will be busiest starting about a month before training delivery and lasting until about a week after Go-live.  Also consider how many people will be impacted by the project and how geographically diverse they are.  Finally, talk to your leadership about their expectations for communications.  I had one client who wanted marching bands and giveaways.  I had another client who thought it was excessive when I wanted to send out training reminders.

Change Management:  Change Management is more than just training and communications.  As appropriate for your project, build into your plan activities such as Super User Networks, Executive Sponsorship activities, Stakeholder Management tasks, Change Readiness Assessments, and Change Impact Assessments.

Project Management:  Now is the time to have a frank conversation with the Project Manager about where you want to draw the line (or not) between Change Management and Project Management activities.  This is an ongoing debate that I won't address here.  Suffice it to say that you should determine what will work for your project and plan accordingly.  Discuss who will conduct activities such as project and phase kick-offs, lessons learned sessions, and presentation development and delivery for Sponsors.  These activities take a lot of time, and it's important to know who will be responsible for them.

Administrative Tasks:  Finally, if you've planned all of these activities and they will require every second of every day for every Change Management team member, you need to stop and re-evaluate.  First, remember that everyone needs a bathroom break at some point.  Second, keep in mind that unexpected activities will arise and you need the flexibility to absorb those that fall to Change Management.  Third, you need to build in time for administrative tasks.  They may not be high on your list of fun things to do, but you still need to take the time to update your work plan, review and approve work done by other people, and attend meetings.  If you forget to plan in time for these activities, you will quickly find yourself falling behind or working a lot of overtime.  I've heard people say that a good rule of thumb is to expect administrative tasks to consume 10% of your work hours.  Unfortunately, I find it tends to be more.

Contingency:  Most projects build some amount of contingency into their work plans.  It never hurts to build a little into your team's plan, as well.

A final note:  One of my favorite phrases comes from the world of SCUBA...Plan your dive.  Dive your plan.  Finding the right balance between this philosophy and being flexible enough to roll with the punches that are part of any project is the true test of anyone responsible for managing part of a project plan.

Let me know:  How much time do you devote to administrative tasks each week?

Change Management in the Project Lifecycle: Pre-project Phase

In my last post, I provided an overview of the eight basic phases that make up the project lifecycle.  Now it's time to dive in and look at how Change Management fits into each of these phases.  Please note that I won't be able to include every single Change activity that could happen in a phase.  That would turn this into a text book rather than a blog post.  I will cover the major activities, though, and if you include them in your plan you will be off to a great start.

Let's get detailed.

Practical Change Management Activities in the Pre-Project Phase

Unfortunately, I often see Change Management - and Change Managers - left out of the Pre-project phase.  Because many people think of Change Management as just communications and training, they assume that they don't need to worry about it until later in the project.  This is a great way to doom the Change program before it even begins.

If you're going to be the Change Manager, now is the time to speak up and jump into the fray.  You need to ensure that the following items are given serious consideration by your organization's leadership...and included in the overall scope of the project:

• If you're partnering with a consulting firm, at least one consultant should be a Change Manager.
• Just because they agree to have a Change Management consultant doesn't mean they can remove you from the project.  At least one person from the organization needs to be a full-time Change Manager, as well.
• Change Management needs its own budget.  Activities involved in communications, training, Super User Networks, etc. can add up.  While there are lots of ways to do it on the cheap, for the most part, you get what you pay for.  If leadership hesitates, show them this fact from IBM's Making Change Work study: "Our study found that project success rates were 23% higher when the amount invested in change was greater than 11% of the project budget."
• If it's a technology project, training should be included in the technology budget.  Training development uses a lot of server space, and you need to consider if your company has a Learning Management System (LMS) available to host any computer-based training courses.
• Make sure that the number of Change Management team members is commensurate with the amount of Change Management work.  Very few change programs can be fully executed by one person.

If you're brought onto a project in a later phase and discover that these items weren't taken into consideration, never fear.  There are ways to address this, which I'll cover in a future post.

Let me know: In your experience, is Change Management adequately addressed in the Pre-project phase?

Change Management in the Project Lifecycle: Project Phase Overview

Forgive me, readers, for my extended absence.  I'm going to start the new year by getting extremely practical.  The next series of posts will focus on the nitty-gritty of preforming fundamental Change Management activities.  If you've been assigned to run a Change Management program but don't know where to start, these next few posts are for you.

Let's start by talking about how Change Management fits in with the overall project lifecycle (I'm assuming here that you are working on a project of some kind - technical, business process, organizational re-design etc.  I'll note that Change Management doesn't always happen in the context of a project, but for the record, I consider change for the sake of change to be a losing battle.)

Most projects have eight basic phases: Pre-project, Plan, Analyze, Design, Build, Test, Implement, and Post-project.  Different companies will use different names for the phases, and you often won't see Pre-project, Plan, or Post-project on the official project work plan, but in general, these are pretty standard.

For anyone who hasn't worked on a project before, I'll begin by providing:

A Practical Understanding of Project Phases

Pre-project: The Pre-project phase typically doesn't appear on the project work plan because, as its name suggests, it occurs before the project begins.  The team is typically very small at this phase.  They are focused on building the business case for the project, which explains the business reasons for doing the project (why do we need to do the project, what are the benefits of doing it, what are the risks of not doing it, etc.), and is often used to get approval from senior leadership to move forward with the project.  For technical projects, this phase also consists of selecting a technology and vendor.  Many companies also choose to partner with a consulting firm, which is chosen during this phase.  Usually, by the end of this phase you will have permission to do the project, vendors and partners selected, a budget, and a general time frame for the project.

Plan: As you may have guessed, during the Plan phase you create a project plan (also commonly referred to as a work plan).  This plan lays out what activities need to happen, when they need to occur, how long each activity will take, and how many people are needed to compete the activities.  Developing this plan allows you to determine how many people you will need on the team at any given time, as well as the skill sets you will need over the course of the project.  This is also the time when the general project time frame you determined during the Pre-project phase becomes more precise.  For technology projects, you will also be able to use the plan to figure out when you will need to procure physical assets, such as system licenses and extra servers.

Analyze: During the Analyze phase you will dive into requirements gathering.  This is your chance to determine exactly what your organization needs from the project.  This phase helps to ensure that the finished product meets your technology, process, and cultural needs.  Once you've gathered the requirements, this is also the time when you will do a gap analysis.  How well does your project as currently planned meet your requirements?  Any gaps will need to be addressed as part of the project, which means you will need to go back and re-assess your project plan, including budget, timing, and people resources.

Design: Now that you know your requirements, it's time to design your project to meet those needs.  For technology projects, this means designing the system.  For an organizational redesign, this means designing the new organization.  A business process project will design new processes.  (A quick note - I talk about different types of projects, but it's very common for one project to contain aspects of each of these project types.  In fact, it's best if your project has at least two of these types.)  The Design phase is often called the Blueprint phase because by the end you will have the blueprint of the project you need to create.

Build:  With your design in place, you're ready to begin the Build phase.  This is the phase where you make your design a reality.

Test:  Once you've built your project, whether it's a computer system, new business processes, or an improved organizational design, it's important to test it before rolling it out to the entire organization.  There are a number of steps involved in the Test phase, but to make it simple, by the end of this phase you should feel confident that the product you built works the way you designed it and meets the requirements you gathered.

Implement:  This is the exciting phase.  During the Implement phase you roll your project out to the organization, letting everyone see/use/participate in/experience the finished product.  By the end of this phase, most of the consultants will leave and many of the people from the organization will go back to their day-to-day jobs.  And, if you did your job well, you'll be receiving positive feedback about the product you created.

Post-project:  This phase often isn't on the project plan mostly because it often gets forgotten.  Just because the project has been implemented doesn't mean the work is done.  There are short-term activities, such as officially closing down the project, closing the budget, and immediate end-user support.  You may also have long-term activities, such as follow-up analysis of how successfully the new product is being used by the organization and continuous improvement cycles.

Now that you understand the project lifecycle, the next question is, "How does Change Management fit into each of these phases?"  In upcoming posts I'll address this question, explaining the Change Management activities typically completed in each project phase.

Let me know: