Defining Business Processes

When a large enterprise project kicks off, the hope of every project manager is that the customer organization has done a thorough and thoughtful job in defining their current business processes. Implementing a new enterprise solution usually means that some significant areas of the organization are going to change. Things have been done one way up until now and it is time that the organization change those things with the implementation of the enterprise solution that they are now incorporating.

To know exactly where they want to go and for you to know how to get them there, there must be an understanding of where they are coming from. That is usually going to come from subject matter experts (SMEs) within the customer organization and they will be the key individuals to define what those “as-is” business processes are so you can better understand how to get them to the “to-be” business processes that they want to experience.

Defining The As-Is Processes

Before a the customer can improve a process through a project such as we are discussing here, they must understand how it works. The most useful tool for studying the current process is a flowchart. There are other ways, but the key is they need to know how their business processes currently work in the area that will be affected by the project before they can truly help the vendor – your project team – implement an effective solution.

To develop an accurate flowchart, the team assigns one or more members to observe the flow of work through the process. If current SMEs are available, this step may be either unnecessary or very fast, but it has to be handled. It may be necessary for the observers to follow the flow of activity through the process several times before they can see and chart what actually occurs. This record of where actions are taken, decisions are made, inspections are performed, and approvals are required becomes the “as-is” flowchart. It may be the first accurate and complete picture of the process from beginning to end.

Here is a very vital piece of the puzzle: as the team starts work on this first flowchart, they need to be careful to depict what is really happening in the process. They don’t want to fall into the trap of flowcharting how people think the process is working, how they would like it to work, or how an instruction or manual says it should work. Only an as-is flowchart that displays the process as it is actually working today can reveal the improvements that may be needed. It’s easy start thinking too early about the “to-be” processes…the focus must be on the “as-is” processes.

When teams work on processes that cross departmental lines, they may have to talk to people at all levels across the command who are involved in or affected by the process they are working on. It is even more important to get an accurate picture of these cross-functional processes than those whose boundaries are inside a work unit or office.

The team can define the current situation by answering these questions:

• Does the flowchart show exactly how things are done now? If not, what needs to be added or modified to make it an as-is picture of the process?
• Have the workers involved in the process contributed their knowledge of the process steps and their sequence?
• Are other members of the command involved in the process, perhaps as customers? What did they have to say about how it really works?

Summary

This is one way to go about it – and it may be done before you even get the project handed to you. However, it’s been my experience nearly 50% of the time that the customer organization has not done a very thorough job of defining their business processes. The overall affect to the project usually plays out in added resource effort resulting in a budget issue and added timeframes up front resulting in project timeline issues.

If the layout of processes is non-existent, it may even be necessary for the project manager to request a delay on starting the project to give the customer SMEs sufficient time to adequately analyze the current business processes in the organizational areas to be affected by the project. That will be painful, but it will pay huge dividends in the long run.

Project Transition to Production Support

As part of methodologies I’ve previously discussed, the final phase is something that I call the Post-Deployment phase.  Once the project is implemented – or deployed – the delivery team, the customer, and the project moves on into the Post-Deployment Phase.

The Post-Deployment Phase is the period of time when the delivery team remains as intact as possible to support the customer and the deployed solution before a final and formal transition to technical, or production support.  This post-deployment period is usually somewhere between 30 and 90 days in length (30 is more likely) and that time period is set either during the sales process (and becomes part of the statement of work) or during the kickoff session.

Upon satisfaction of the post-deployment timeframe, support formally moves over to the company’s techical or production support team.  The template I am unveiling here is a formal document to record that transition process, allowing the project delivery team to identify specific things about the project that the production support team will need to know.  While reviewing this document, keep in mind that there are really three very key pieces of information in here that the support team will need to know the most about:

• Schedule
• Communication
• Change Control Process

PROJECT TRANSITION TO PRODUCTION SUPPORT

[Save file name as: client name PRODUCTION SUPPORT yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work performed.

SCOPE

Describe the deliverables/actions to be supported. Provide additional documentation as appropriate.

SCHEDULE

Describe the timing for support activities to be performed. Provide additional documentation as appropriate.

COMMUNICATION

Describe all required communication needs for support – What to communicate, to whom, in what format, and when. Provide additional documentation as appropriate.

QUALITY ASSURANCE

Describe the Q/A processes to be performed. Provide additional documentation as appropriate.

COST

Describe the support costs estimated by the project. Provide additional documentation as appropriate.

CHANGE CONTROL PROCESS

Describe how changes to the Production Support process will be addressed. Provide additional documentation as appropriate.

Kicking Off a Small Internal Project

Fundamental project management is basically the same across all projects, but how much formal project management practice goes into it does depend a lot on things such as overall timeframe, budget, internal vs. external project, and project criticality and visibility. Let’s face it, these all play a role in how much effort is allowed to go into a project…budget being a huge player.

For small, internal projects that aren’t very visible, aren’t very critical and don’t involve an external revenue generating customer, the circumstances for managing the project and the effort that goes into it are going to be fairly small. For the purposes of this article, I’d like to use Michael Thomsett’s description of how a project manager might kickoff an internal project as described in the Project Announcement Meeting section of his book “The Little Black Book of Project Management.”

I do not necessarily agree with or endorse the information set forth in this article, but I do find the information helpful and it is undoubtedly useful information given the right situation. In a future article I will submit my own viewpoint on the processes for getting a small internal project underway.

The Project Announcement Meeting

Getting your project off to a healthy, well-defined start depends on your approach: how you lead, how you seek definition, and the initial organization of the team, schedule, and budget. But it’s also necessary to communicate your purpose and approach to your team. Thus, a project announcement meeting is essential.

Do you really need an announcement meeting? It may be possible to set the tone and define your purpose without gathering people together; but a preliminary meeting can save a lot of time and effort later, and can help avoid misunderstandings about authority levels and the nature of the assignment.

Example: An accounting manager was assigned the project of setting priorities for automation. The task included interviewing the heads of each department and recommending routines that should be given priority. But the department managers were not advised of the project. The accountant found these managers to be defensive and suspicious; they weren’t sure whose idea the project was, the accountant’s or top management’s. A great deal of effort went into explanation, and the project proved difficult to complete.

This project could have been executed more efficiently if an initial meeting had been called. The accountant and each department manager should have been invited, as well as the executive who made the assignment.

If an announcement meeting is not called at the time a project is assigned to you, recommend calling one. The executive should briefly explain the purpose and objective of the task and clearly identify you as the project manager. Once everyone understands what you’ll be doing, it will be easier for you to organize your project team and contact the resources you’ll need. Most of all, a brief meeting will help avoid your having to explain what you’re doing and why, or having to deal tactfully with other managers who have not been informed about your project.

Support your recommendation for the announcement meeting with these points:

• Announcing a new project defines it for everyone involved, and clarifies the intended purpose. If the meeting is not held, definition will be a problem each time you have to contact a resource.
• The meeting helps ensure success, because everyone gets the message at the same time and from the same authoritative source. Your ability to lead the project team is aided when the project is launched from the top.
• A demonstration of executive support for the project manager helps the team to achieve its goals. However, it’s important to let others in on the decision when they or employees reporting to them will also be affected, either as a team member or as a resource for the team.

If you have identified your project team by the time the announcement meeting takes place, each member should be invited along with individual managers or supervisors of their departments. Introducing the project to everyone—team members and their supervisors—makes your job of working with other departments much easier.

There’s a significant difference between trying to achieve a project task that conflicts with departmental goals and working with other managers to resolve problems. Inviting the managers to the initial project meeting makes them feel included in the process. That sets a positive tone and helps you to function as project manager. The alternative is having to continually struggle with a manager who was left out of the decision-making process at the beginning.

PM Best Practices for the New Project Manager

PM Tips is designed to be a discussion area and information source for both the experienced project manager and project managers with little to no experience. For PMs with a significant amount of experience, many of the things that are generally considered ‘best practices’ are things, hopefully, that we do without even thinking.

For the new PM, however, these concepts can not be taken lightly as they may not be intuitive yet and newer PMs may even be working in an organization that provides little to no support for the PM process. In some smaller organizations or companies where IT is a sidebar rather than a primary focus, the newly anointed PM may be standing alone trying to get their arms around a portfolio of ‘projects’ in various stages of disarray.

How do you jump in and take over managing in this type of situation. I’d like to discuss that at length and share my thoughts, but that’s probably for another article. Here, I’d like to discuss some of the ‘best practices’ that the new PM should employ as basics to getting started on the road to good, solid, project management performance. Paying close attention to these 5 key areas will help the project manager stay on track toward a successful project conclusion. The degree of effort that is put into any of these areas depends on the size, timeframe and budget for the project, but they all must be performed.

Scope Management

Get a good handle early on as to the proposed scope of the project that you’ve been handed. Gather as much info concerning the scope from whoever closed the deal and handed you the project. Jot down any project requirements you don’t fully understand and be sure to discuss those in detail with your customer before or during the kickoff meeting. This proposed scope is critical because it is the basis for the project, the input for the project schedule and ultimately what your project will be judged against.

Reporting

A good rule for the PM, at a minimum, is to provide your team and your customer with the following, in terms of project reporting on a regular basis:

• Weekly project status report
• Weekly budget status/forecast update (if applicable – discuss with your customer early on)
• Weekly revised project schedule

The project status report will be the document that drives the weekly status call with the customer and the weekly revised project schedule will be what shows the team and the customer whether or not the project is on track and will let each team member what their responsibilities are for the week and for the rest of the project.

Budget Management

It’s imperative that the PM management the budget and the forecast (both financial and resource) very closely. Whether that gets shared with the customer regularly may be a matter of corporate policy or may be based on your customer’s preferences. But at the very least, the PM must be on top of this at all times.

Losing control of the budget and the forecast – which can be relatively easy to do – can cause major problems down the road as the project nears completion. Finding out in the late stages that you’ve run out of money is hard news and sharing it with your customer as a ‘surprise’ will not only result in great customer dissatisfaction, it may either get you pulled from the project or it may get the project canceled on the spot. Both are bad for your career.

Timeline Management

The project schedule is what lays out the entire timeline for the project identifying key deliverables and milestones. As mentioned in Reporting above, the project schedule is a critical piece of information for each project team member and must be revised and distributed weekly to everyone.

I’ve not managed a project yet where the original project schedule remained unchanged throughout and I just managed from it. Because of change orders, issues, customer preferences, or revolving project resources, there are monthly, weekly and sometimes daily changes to the project schedule. Those must be accurately noted and distributed to the team and the customer on at least a weekly basis.

Customer Communication

As the Project Manager, how and what you communicate to the customer will go a long way in determining customer satisfaction on the projects you manage. Keep them engaged in all critical project communication. Don’t keep the bad news from them…but don’t tell them the sky is falling all the time either. If you have bad news to share, be well prepared to deliver it. In fact, it’s best if you already have a planned course of corrective action. But if not, share it with the customer and ask them to share in the corrective action. It’s their project, too…and they want you to succeed.

When the Path to Project Success Narrows

When your project starts, the whole world is at your fingertips. Everything is new and fresh…even your team of talented resources believe everything you say and accept all the tasks thrown their way. Because it’s a new project, full of optimism and hope. Fluffy…fluffy.

Now, fast-forward 6 months and look around. What happened? Your 6-lane interstate that you were driving on has become a 2-lane blacktop. You’re running dangerously close to the edge with every turn and every bump. You’re just one wrong move from completely losing control and you’re trying to figure out what happened to the slack time, the confidence, the enthusiasm and the teamwork.

Optimism Reigns Supreme

When you first start out on a new project that is new and fresh and all yours to either succeed with or sink like a rock, optimism reigns supreme. You can do anything with it – your thumbprint is all over it and it is your baby. The customer hangs on your every word. Your team is genuinely interested in everything you have to say. And the project budget….it’s wide open…there is so much money remaining…it’s virtually untouched, except all that money that was chewed up in the past two weeks first getting ready for and then flying to and conducting the kickoff meeting at the customer site. But other than that, it’s all there and ready to be gobbled up by resources anxiously waiting to work with you on a successful project and maximize their billable time.

The Honeymoon Is Over

Soon, though, reality sets in. It’s like when you’re newly married and you have all those wedding presents and money gifts and a good paycheck that was definitely enough for you and should be enough for the two of you. Eventually it hits you that what you thought was a surplus is really barely enough to get by…so you darn well better pay attention and manage it closely.

The same holds true with the projects we manage. Early on the project schedule is laid out before us mapping out every task showing how we’re going to complete the project on time eight months from now. The project buck of money is full to the brim and ready for resources and travel expenses to get charged to it. But remember, just because you have checks left in the checkbook doesn’t mean you still have money in the bank. That project money bucket can empty fast if you don’t manage it well. And the same holds true with the project schedule. First one task runs over its allotted timeframe. Then another one. Then a major one slides and suddenly you find yourself dialing the customer’s number to explain your eight-month project will now be a ten-month project and you’re not sure why.

Summary

As project managers, we have to be in control. Nothing can be left to chance. Those first few months – the honeymoon on a long-term project – are exciting and full of progress and successes. It’s the period near the end where issues arise, risks are realized, and glitches and scheduling conflicts happen that can derail what appeared to be a successful project so fast it will make your head spin.

How can we avoid this? The answer is we can never full avoid it. But aggressive preparation and planning can take us a long way in trying to avoid a negative outcome. Identify the issues, manage for the risks…and discuss them often, truly manage the budget as if it were your own money, and revise that project schedule with realistic information at every turn. Monitor it daily and manage it weekly. Success doesn’t happen by luck. The true road to project success is not paved in gold…there is a lot of carnage on that road. And it is narrow…not wide as it appears at the beginning of a project. Plan well and understand how things can impact your project’s chances for success and act accordingly.