Author: Ronald B. Smith, MBA, PMP
Ronald Smith has over four decades of experience as Senior PM/Program Manager. He retired from IBM having written four books and over four dozen articles (for example, PMI’s PM Network magazine and MPUG) on project management, and the systems development life cycle (SDLC). He’s been a member of PMI since 1998 and evaluates articles submitted to PMI’s Knowledge Shelf Library for potential publication. From 2011 - 2017, Ronald had been an Adjunct Professor for a Master of Science in Technology and taught PM courses at the University of Houston’s College of Technology. Teaching from his own book, Project Management Tools and Techniques – A Practical Guide, Ronald offers a perspective on project management that reflects his many years of experience. Lastly in the Houston area, he has started up two Toastmasters clubs and does voluntary work at various food banks.
The Shape of Performance Reporting
An Outline that Can Be Used for Tracking Progress It could be said that communication is the oil that keeps a project running smoothly. Project managers (PMs) can spend up to 90 percent of their time on internal and external communications. Communication management includes project status tracking and reporting processes. A schedule for such should be defined at the start of any project. That is, a description of the information needed for the sponsor, the stakeholders, and the project team. An overall plan should cover who needs what, when they need to know it, and in what form the information should be delivered. There are many ways of reporting the status of a project. For example, Microsoft’s Project, Excel, Visio, PowerPoint, SharePoint, and/or email. Status reports describe where the project stands at a specific point in time, and in terms of the triple constraints (meeting scope, time, and cost goals). Status meetings, whether held weekly or monthly, provide a forum for stakeholders and the project team to discuss expected progress for future meetings, risks, and most importantly issues and their resolutions. Let’s look at some of the approaches that can be utilized for tracking a project’s status and communicating it. See Table 1.1 for an example of an Issue Log and Table 1.2 for an example of a Risk Register. Keep in mind if an organization spent more time on risk management upfront, they would have fewer issues to deal with and in the long run would save money and probably end-up with a better finished product. Reporting Task Progress Getting updates from project task resources, like percentage completed, is usually time consuming and often can be a minefield. For example, resources are often optimistic. They may think they can make up for lost time in the next reporting period, or may not want the PM to know if they have fallen behind. It could be that they are being over-loaded by multiple projects or part-time restraints. A PM needs to grasp project progress as accurately as possible, so people have confidence in the overall timeline of the project. The following are the only three task percent completions that I would recommend using in a project plan: 0% – Task not started. 50% – Task has started. Each organization should pick a range number to go with based on their past experiences. Hopefully it will be between 25% – 50%. Going with 25% is to choose conservative progress reporting. This is wise in situations where participants won’t be overly optimistic or a safe approach is needed. Going with 50% completion means taking the middle of the road. You’re assuming about half the tasks are less than 50% complete and the other half are near completion. Keep in mind just about every project has a few tasks that always seem to be at 90% complete. Whenever a planned start and/or finish date is reset, leave the “old” date visible (e.g., in another cell) which allows revision history to be shown. 100% – Task is completed. One of the first things I do when I am reviewing the progress of a project plan is to sort the percentage complete fields (from low to high) and look at the status of the three task completion statuses (0%, 50%, and 100%). To begin with, I am mainly interested in finding tasks that should have started and didn’t and finding out the reasons why. I am also interested in tasks that are about to start. When I look at the status of tasks that have started, I am mainly interested in finding tasks that look strange (for example, missed completion dates, on the critical path, and/or the completion date is fast approaching, over-taxed resources, or those that are always 90% complete) and following up with some detective work. I usually don’t spend much time looking at tasks that are completed because, of course, they are history. Obviously the more tasks I see completed, the more confidence I have in the progress being made and in meeting our timelines. Microsoft Project has several graphical reports that pinpoint tasks that need help. Some of the reports include Critical Tasks, Critical Tasks Status, Upcoming Tasks, and Late Tasks. Project also has several graphical reports that help a PM manage resource over allocations. Those are Resource Overview, Over allocated Resources, and Resource Work Summary. Microsoft Project Project Statistics provides a 20,000 foot overview of the project status, which is very useful in quickly seeing the current big picture. In the Project tab’s properties section, click Project Information to see project information. Data for a new project that has not been baselined will show as in Figure 1.1 below. As you can see, this project is scheduled to start 6/27/17 and finish on 10/4/17. You can click the “Statistics” button at the bottom to bring up project statistics for the project. See Figure 1.2. Right after the project is approved and baselined (in the Project tabs schedule section, click Set Baseline for the entire project). The project statistics will now show the baseline fields, as in Figure 1.3. It’s important for the PM, during the execution of a project, to periodically check the statistics to see if the project is behind schedule, on schedule, or ahead of schedule. Figure 1.4 shows that everything is on schedule (that is, duration and work percentages are equal and variances are zero). This is not typical because project performance statistics tend to drift away from baseline values during execution. For example, if the duration % is greater than the work % then you will have a finish variance greater than zero, meaning you are behind schedule and have to work on a recovery plan to get back on track. Variance is usually measured as time, such as days behind timetable, or as cost, such as dollars over budget. Baselining is a method for analyzing a project’s performance (original values vs. current values) and is a significant component of overall project management. There are dozens of new graphical reports (thank God for the elimination of text reports) in the latest versions of Project that are easy to digest and customizable. Once a project is underway, you can use high-level and detailed-level reports to see if a project is on track. If it isn’t, you’ll be able to easily find the troubled spots. Graphical reports are covered in the Report tab’s “View Reports” section, and most of the selected report categories have the option of “More Reports.” See Figure 1.5, which shows the various highlighted Dashboard reports covering broad schedule and cost variance reporting. Report categories are as follows: Dashboards – Repots such as Burndown (work done and what’s left to do), Cost Overview (includes historical and future cost trends), Project Overview, Upcoming Tasks, and Work Overview (presents work status from several perspectives). Project Overview focuses on overall progress of summary tasks and milestones. These are excellent reports to share with project stakeholders who need big-picture status. Resources – Over allocated Resources and Resource Overview reports. Costs – Cash Flow, Earned Value, Task Cost Overview, Cost Overruns, And Resource Cost Overview reports In Progress – Reports such as Critical Tasks, Late Tasks, Slipping Tasks, and Milestones. Getting Started – Includes Best Practice Analyzer, Get Started With Project, Share with Your Team, Create Reports, and Organize Tasks. All the above graphical reports can be customized. Project’s Visual Reports (to the right of the above mentioned View Reports section) use Excel charts and Visio diagrams, so you can drill down into the data to find problems. Excel and Visio take advantage of the pivot table notion, which is a data utility tool found in data visualization programs such as spreadsheets or business intelligence software. This tool allows for Project’s selected exported data to be looked at from different angles/rotations or pivots. It sounds like a Rubik’s cube, and put quite simply, it allows the user to decide how data is presented. A list of available visual reports can be found in the Report tab’s visual reports (export) section. See Figures 1.6 and 1.7. The Excel visual reports available allow you to customize the exported data the way you want to by using the PivotChart Tools heading that appears above the ribbon (you can then save the report as an Excel file). Likewise, the Visio visual reports allow you to customize the exported data by using the PivotDiagram task pane and save the report as a Visio file. The only common visual report between Excel and Visio is the Cash Flow report. Between the graphical and visual reports, your project is covered in areas of overall project status, financial performance, task management, and resource management. Summary “When you fail to plan, you are planning to fail.” This is a quote from Dr. Robert Schuller, a pastor and motivational speaker. A similar sediment from John Wooden, who won ten national championships in college basketball (UCLA), is “Failing to prepare is preparing to fail.” Remember that communicating project status to stakeholders and the project team is perhaps the most important function of a PM. Done well, it helps to keep the project on track in meeting its deliverables. The main reason for having project status tracking meetings is to identify potential issues, problems, and risks before they occur and then put recovery plans in place to avoid any damage to the overall project. The PM must continually communicate the status of the recovery plans to the stakeholders and the project team until issues are resolved. As part of a project’s communications plan, I highly recommended a PM hold periodic project status tracking meetings (usually weekly) with a set agenda. PMs will also find that Microsoft Project is a great tool for tracking project status because it has so many useful built-in reports, powerful data filtering features, and the ability to create your own templates/reports!
Don’t Turn your Critical Path into a Slippery Path
In my last article, I covered four misconceptions about critical path. Now, I’ll be going through some of the mechanics of finding the critical path in a project, so that you have a better understanding how it evolves. Keep in mind that Microsoft Project’s software performs similar calculations. Manipulation of the network sequence diagram involves simple calculations used to produce the critical path and non-critical paths embedded in the project network plan. We will assume all activity relationships are Finish-Start (FS) meaning that each predecessor activity has to completely finish before the successor activity can commence. We will also assume that durations are in days. Figure 1.1 shows a visual sample activity-on-arrow (AOA) network. The AOA is a networking diagramming technique in which the activities are represented by arrows and connected at points called nodes to illustrate the sequence of activities. A node is the starting and ending point of an individual activity. The first node represents the start of a project and the last node represents the completion of the project. Path 3, B-D-G-I is the critical path (25 days long) for this small project. Figure 1.2 shows the same representation within Microsoft Project with the red bars displaying the same critical path. Slippery Path On the start date of your baselined project plan, you will know what your critical path is and the planned completion date. The following are a few examples on how a critical path can get real slippery. Sometimes you may have gaps in your critical path due to missing or changing task dependencies, external predecessors, date constraints, or resource leveling. This indicates that your plan is incomplete. You may have multiple critical paths (for example, they could be parallel or they could intersect), which is usually more susceptible to having changes and it’s extremely important for PMs to keep their eyes on all of them to avoid a late project completion. Most of the time a critical task has zero total slack time, but if it has a negative slack time, it might have been generated by having date constraints or locked-in deadlines. These types of constraints are best to use sparingly. In this scenario, it might be difficult to tell what tasks are really critical, but you can get help by using Project’s Task Inspector (under the Task tab) to view factors affecting the task’s start date. You may also find suggestions on how to fix a troubled task from the Task Inspector. If there are two tasks occurring at the same date/time and one is a critical task and the other is a non-critical task, but they both are using the same resource, the PM needs to allocate the resource to the critical task first. Then, the PM would use the slack time on the non-critical task to delay the start of this activity. Going through this exercise prevents the critical path from changing and extending the project’s completion date. Microsoft Project There are many ways to look at and monitor the status of a project plan’s critical path to see if it’s becoming slippery or changing. For example, showing critical tasks in the Gantt chart view as shown in Figure 1.2. The left pane shows the columns for field values, and the right pane shows the Gantt chart timescale. If you right-click the left side pane, you can insert the “critical” column to find out if the tasks are critical or not. Furthermore, if you right-click the left pane, you can insert the “Total Slack” column, and if you see zero, you’ll know it’s a critical task. Otherwise, the project doesn’t consider it a critical task. Click the View tab, and then select the “critical” filter. The critical task bars appear in red (similar to Figure 1.2). Click the Format tab, and then select the Critical Tasks check box. The critical task bars appear in red. Click the Report tab, and then In Progress reports. You can select Critical Tasks to gets its report, which includes the name, start, finish, % complete, remaining work, and resource fields. Click the Report tab, and then in Visual Reports. Then select Microsoft Visio’s Critical Tasks Status Report. From here, the selected data from project is exported to Visio, and is displayed as a hierarchical thumbnail graph that shows the percentage completed for each critical task. You can rearrange, format the report, and save it as a Visio file. Summary Understanding both the critical path and slack concepts is vital for effective time management and requires that the PM keep these parameter values in mind as the project unfolds. Understanding task slack (or float) gives the PM flexibility in scheduling the start of a particular activity, which helps to facilitate prioritization of resource allocations across the project plan. If you want to shorten a project’s duration, always concentrate on what can be done to the activities that make up the critical path, but keep in mind this usually is not a trivial exercise. Typically 20% or fewer of all the project’s activities are ever on the critical path. Also, when you shorten a project’s duration, you must remember the project’s triple constraints – time, cost, and scope. If one of the constraints has to change, it will alter one or both of the other constraint(s). For example, if you have to decrease the duration (time), you might need to increase budget (cost), because you have to hire more resources to do the same work in less time, or you might have to reduce the scope of the project. Always double-check your project plan. Mistakes, like missing tasks and/or duplicate tasks, can linger affecting your critical path. For example, task dependencies that should not be there, tasks with no resources assigned, summary tasks that have resources assigned, over-allocated resources, and duration values that seem too high or low. Make sure you have enough milestones (important events or accomplishments) in your plan for project status reporting and the durations to equal zero. Milestones are like traffic signs, a signal that you have reached an important point or decision in a project. I have seen many project plans that have no milestones, have only one milestone of “end of project”, have milestones without zero durations or assigned resources. This is always a red flag that this project plan is not well thought-out! Don’t let such happen to you!
Four Misconceptions about the Critical Path
Most non-technical people don’t know what the critical path is; whereas, those that work on IT projects know what it means at a high level, but have few insights into the actual mechanics of it—and how quickly it can change the outcome of their projects! The truth is that there are many misconceptions about the critical path. Let’s cover some of the major ones: Misconception: The critical path is the shortest path through the network diagram. Fact: The critical path is the longest path through the network diagram, meaning the sequence of activities that collectivity define the starting and ending dates for the project and have no slack or float time (excess time). Conversely, non-critical paths have slack time which is the amount of time a task can slip. This provides you wiggle room without delaying the tasks that follow it and doesn’t alter the completion date. Misconception: Every task on the critical path is critical. Fact: The word “critical” in this context usually has nothing to do how important these tasks are to the overall plan, but instead refers to how their scheduling will affect the project’s finish date. Also, people have to remember after a task on the critical path is completed, it’s no longer “critical” because it cannot affect the plan’s finish date. Misconception: The critical path will never change. Fact: Every project has at least some changes (for example, scope, time, and/or money) which means the critical path(s) will change. This will result in a new expected completion date for the project. Other reasons why the critical path will change periodically is because some of the tasks will be completed ahead or behind schedule, and/or task relationships can change. Misconception: If you shorten the length of a task on the critical path, then the project will be completed sooner. Fact: It depends! If you do this, more than likely the “shortened” task on the critical path could be replaced with a longer, non-critical task that now becomes a critical task. This means you have a new critical path(s) and a new completion date. It’s important to remember that reducing the critical path on most projects to shorten a project’s duration is not a trivial exercise, can be downright strenuous, and can lead to other problems. For example, you could be increasing your project risks leading to a rework situation. Of course, there are ways and techniques that can possibly shorten the length of a project to meet a certain deadline if done correctly. For example, the scope of the project could be reduced and/or have more people assigned to work on critical tasks helping to compress the schedule. In my next article, I cover some of the mechanics of finding the critical path in a project, so that you have a better understanding how it evolves. We’ll also look at manipulation of the network sequence diagram.
Split It Out (Part 2)
More Ways to Separate your Project into Manageable Chunks In Part 1 of my article “Split It Out,” we looked at ways to separate projects task into smaller parts or pieces that are more controllable. Let’s look together at a few more areas that can be split out for project success! Partnering it out In today’s highly sophisticated industrial environment, it is often best to partner with other organizations that can perform special segments better (for example, subject matter experts), rather than doing it all in-house. Often called “outsourcing,” these types of partnerships are increasingly employed in current projects. A PM partners with third party vendors and obtains buy-in from the various performing organizations. It is important to remember that most outsourcers report to the PM, and it is vital for the PM to document everything they have accomplished for historical/reusable purposes, before they “hit the road.” In addition, even though the project’s sponsor might hold the purse strings, the sponsor, at times, needs to be partnered with the PM by providing him or her with continued support and involvement. Phasing it out Every project should be broken down into at least four phases: Initiation, Planning, Execution, and Closure. There are many IT resources that incorporate these phases and related tasks into a project template. The Initiation phase is usually the short piece of work that includes preparing the business case, project charter, preliminary scope statement, and assembly of the team. The Planning phase is about finalizing the scope statement and creating a WBS hierarchical structure with its level of WPs, which include summary tasks, milestones, cost planning, communication planning, risk management, and procurement processes. Always look for WPs that don’t support the scope statement and for WPs missing from the scope that should be included. Generally, the more time you spend on planning to get it right the first time, the less time you will spend on execution. The Execution phase is where the bulk of the work is done. This includes the big task of monitoring and controlling your work to make sure you stay on track, and managing risks, issues, and changes. The more tools (for example, Microsoft Project) and techniques PMs have at their disposal, the easier this phase will be to influence the outcome of their project in a positive manner. The Closure phase is similar to the initiation phase. You want to keep it short and simple. Closure activity should primarily be that of getting acceptance sign-off from the client that the project was successfully completed. There may be other closing processes like tying up loose ends, capturing lessons learned for future projects, and thanking the team for a job well done. Programing it out If you have a software development project, the first step should be deciding which methodology model to use because this will have a profound impact on controlling the schedules, costs, and the quality of the project. Choosing a model depends on many factors like project size/complexity, need for user/customer involvement during development, available tools, and staffing profiles. Historically, most software projects used the waterfall model for scheduling projects because it was the first or earliest process model to be introduced. This process is called the linear-sequential life cycle, which means any phase of the development process begins only when the previous phase is completed. This is also a predictive life cycle model because the scope, schedule, and cost can be predicted accurately. Generally, this is well suited for medium to large projects with well-defined requirements. In contrast to predictive models, there are adaptive life cycle models where the software requirements are not clearly defined, and therefore, the software is developed using a less structured approach. An adaptive approach is either iterative or incremental. An iterative approach starts with a simple implementation on a small set of software requirements with iteratively enhanced growing versions building upon one another until the system is completed. Incremental means each build is a step beyond the previous one l in terms of features, and that the final build holds all the features required by the customer. The fastest growing adaptive model being used today is Agile, which is really a combination of the iterative and incremental approaches. More and more organizations are using a hybrid model (waterfall/Agile) for certain projects, and future versions of Microsoft Project will include more Agile features. Resourcing it out A big part of resource planning includes resource leveling and reallocation, which is one of the hardest things for a PM to do. In essence, a PM needs to make sure to have the right resources at the right time to successfully complete the project. The main purpose of resource leveling is to avoid resource conflicts, so you can have a smoother distribution of resource usage. For example, you may have a person scheduled to work eight hours on a critical task and another eight hours on a non-critical task on the same day. Obviously this person can’t work on both tasks at the same time and you would want the person to work on the critical task first, so the planned finished date for the project is not altered. This means the non-critical task should be delayed to a different date or different dates (for example, 4 hours/day). The following are some other work arounds for resource leveling and reallocation. Rearrange task sequences to eliminate resource conflicts without changing the project’s end date. This is usually the easiest and the first thing you want to try doing. Work overtime. Remember this could “burn” people out and/or add additional costs. Add more resources, which will add additional costs to the project. Decrease the project scope. This should be done during project initiation and not later. Increase the skill level of the team with appropriate training before the project starts. Microsoft Project can automatically level resources. This usually pushes out the project’s completion date, which some stakeholders do not like. A skilled PM must act like a surgeon and make resource level adjustments to the project plan to meet the project’s completion date. Microsoft Project has many tools for the PM to tweak a task’s resources allow for the correction of over allocations. Risking it out A risk management process identifies tools and techniques to aid in minimizing uncertainty through understanding, assessing, and managing the uncertainty that is inherent in projects. This will aid the PM in maximizing the probability of a predictable outcome. It is important for the PM to categorize risks using headings such as technical, commercial, management, resources, and external. The next step is risk response planning to develop action plan(s) on how the risk can be reduced or mitigated. There are currently four standard risk strategies: accept risk, avoid risk, mitigate risk, and transfer risk (could include sharing a risk with a third party). Large projects will invariably discover new risks during the execution phase. This should be planned for by setting up a Risk (or Contingency) Reserve, through which approved funds from the total base budget can be moved into the WBS structure as a normal work activity. To summarize, the more time an organization spends on risk management in the beginning of a project, the less they would spend on issues and changes during the execution of the same project. Scoping it out One of the most difficult things to do is define the scope of a project. Ideally, you would like to keep the scope small to save time and money, but this doesn’t always happen. A project with a large scope can be difficult to manage, but scope change can also have a similar effect. The purpose of scope management is to help ensure that all the required work is covered and that only work that relates to the scope is completed. In short, the scope statement should include what work is included and what work is not included, which will help to reduce “scope creep.” The boundary lines should include project constraints (for example, limitations on resources) and requirements that must be met (for example, ordered equipment must be received by a certain date). When a PM receives a request for a scope change, he or she must be diligent in knowing that the client isn’t always right, but could be. Bottom line, make sure there is adequate justification for the change. Otherwise, unnecessary changes can turn a good project into a troubled one! Large projects will invariably have “scope creep,” and it needs to be planned for by setting up a scope reserve. Approved funds from this reserve can be moved into the project’s WBS as normal work activity, which would become part of the total base budget. “What if” it out Playing the “what if” game is useful analysis to compare variations (tasks and/or resources) between the current version of a project plan and an earlier version of the same plan. A comparison of this type can be very useful for developing different alternatives for a new project that could possibly save time and money and make stakeholders happier. Furthermore, this analysis can be very handy when analyzing scope changes in a project. In performing what if analysis, always remember to keep a backup copy in case you need to return to your original base. Microsoft Project has a “what if utility” in which you open the original file first and then the updated file. After this, choose Report – Compare Projects. In the Task Table drop-down list, choose the table that contains the fields you want to compare (Note: the default is “Entry” meaning that it will show all the fields in your plan). Do the same for the Resource Table drop-down list and when done, click OK. Then, the scrambling screen magic starts! The Comparison Report will be shown on the top half of the main project window, the current version appears at the bottom left, and the updated version appears at the bottom right. A legend on the top left hand side of the Comparison Report identifies the symbols it uses. For example, tasks that appear “only” in the current project include a “+” sign, and tasks that appear “only” in the previous version include a “–” sign to indicate that they have been removed in the current version. Note that you can save the Comparison Report if you want. Summary As I said previously, following these tips for breaking things down should improve any PMs credibility, performance, and chances of success. A good guideline is to always think in detail! It is also helpful to brainstorm with the people involved in your project by “thinking outside the box” and by reviewing past lessons learned to help eliminate any negative effects when developing your project plan. This topic has been all about planning. Spending more time on planning should lead to less time and effort on your project’s execution; therefore, reducing the total cost. The best PMs know and practice these important processes!
Split It Out (Part 1)
How to Separate your Project into Manageable Chunks Splitting your project into smaller parts or pieces that are more controllable helps you to move closer to your ultimate goal of achieving your project deliverables and high user satisfaction. Planning your project thoroughly means thinking of different ways to break your project down into smaller, more manageable chunks of time and work. This, in turn, allows you to have more direct control and, of course, increases your chances of success. Let’s look together at the different areas that can be split out. Accounting it out Work packages represent necessary work units that need to be completed to finish a project. To have good work package (WP) estimation, it is important for Project Managers and users to know which costs are direct costs and which are indirect costs. This distinction allows a PM to track what is within his control and what is not. A PM is usually held accountable for the “entire” cost, when, in actuality, most indirect costs are beyond the control of the PM. Indirect costs are often combined in various cost pools referred to as overhead. These types of costs could include enterprise machinery, plant, and other indirect expenses associated with the organizational support of the project. These costs are usually allocated (or time-based charges) at the project and/or activity level on a percentage basis with no real explanation. Borrowing it out Starting out with a blank project plan in Microsoft Project is a daunting task, and the last thing you want to do is start from scratch. You don’t have to reinvent the wheel. Borrow ideas from other PMs and/or similar project plans when developing your work breakdown structure (WBS). This will save you time and add value to your overall project. PMI, Microsoft, and Microsoft Project User Groups, like MPUG, provide many resources and/or online project templates you can use. Consider reusing templates from previous projects from within your organization, too. For example, I was once responsible for annual Disaster Recovery (DR) tests for a global services company I worked for. In the beginning, I developed a standard project plan in Microsoft Project with the help of experienced resources. I then used the plan as a template. It included WBS predecessors and durations. Each time I started out with a new client, I updated the template with resources and dates. Doing it this way only took me about fifteen minutes each time I added a client. When the next year rolled around, I took the previous plan for the same client, updated the dates, and contacted the resources to see if they were still available. The annual update only took me about five minutes. Breaking it out To improve control and bring in faster benefits, project cycles and phases are best kept as small as possible. After 12 to 18 months, requirements tend to shift, the overall control of the project becomes more difficult, and a PM will likely be spending more time just monitoring a project. Furthermore, it is more difficult to keep a team properly focused on the correct work after a year, and there is a high probability of team turnover. In other cases, success can be decreased because of advances in the technical environment, or other projects might take on a higher priority (which means your project could be temporarily frozen). If a project runs longer than 12 to 18 months, it is prudent to consider how it could be broken down into defined subsets (for example, phases, state gates, or multiple projects), so that the individual parts can be implemented more rapidly. Buffering it out No plan ever runs according to schedule, and some tasks will come in late, so you will need some wiggle or breathing room. A good idea is to add a buffer task at the end of “selected” phases (for example, limited or no experience users learning new technology). Alternatively, in a case like this, you could manually extend a summary end date for a particular phase by 20% from its’ original duration. If the original phase duration is 100 days, manually extend it to 120 days. If you find out you didn’t need this entire buffer for a major phase, you can always reduce the duration time of the buffer to get an accurate project completion date. Finally, if you find out you defined a buffer task at the end of a major phase and didn’t need it at all, you could delete it or inactivate it (Inactivation removes values from your rolled up schedule). In this situation, I would recommend inactivating the task for historical reasons. Of course, you could always reactivate the buffer task later, if needed. Compressing it out The requirement to shorten a project schedule or critical path is a shared occurrence, and the following are two common practices for doing this: Crashing is the process of adding more resources to a critical task to shorten the time needed to finish a project. This has the impact of adding costs to the task for faster delivery. Keep in mind that adding too many resources can actually slow the task down (for example, getting up to speed, resources getting in each other’s way, training and/or more materials required). Fast tracking involves doing activities in parallel that you would normally do in sequence to shorten the overall schedule. Even though this appears to be a cost-free option, a PM must be careful in doing this because it could turn a critical task into a non-critical task and create new critical path(s) and/or increase the risk of redoing the work resulting in a new estimated completion date. Another approach to “compressing” a project’s schedule is to reduce the scope of the project, which will shorten the length of it. Keep in mind that users and stakeholders must buy into this, and they might not be happy with the end results. Splitting long tasks into several shorter ones can sometimes reduce a schedule. In this case, the subtasks could be assigned to several people that can work in tandem. Owning it out If you see a play and the first act shows a servant with two masters that own guns, you know by the third act that someone is likely to be killed. Likewise, a project plan is made up of an aggregate of WPs (approximately 8 – 80 hours or up to two weeks in duration) that should have only one performing organization owner with an assigned owner per WP. If you have two or more performing organization owners for the same WP, you are opening the door for finger pointing if something goes wrong with executing the WP, especially if the tasks are on the critical path. In this case, the WP should be broken down into at least two WPs to represent the individual performing organizations. Summary Following these tips for breaking things down should improve any PMs credibility, performance, and chances of success. Remember, when decomposing your project down into WPs, don’t allow gaps or overlaps. By allowing no overlap, you are identifying all components of the deliverable you are decomposing. Furthermore, you don’t include the same sub-product in your decomposing of two or more deliverables. I’ll be sharing more ways to separate your projects into management chunks in Part 2 of my article.
No Pain, No Gain?
Turning Project Financial Analyses into a Painless Exercise Introduction “No Pain, No Gain” is a popular exercise slogan that promises greater rewards for the price of hard work to achieve physical excellence. In the field of information technology (IT), most people think that performing financial analyses on new projects is hard work, but it doesn’t have to be if you know what you are doing. First off, you have to realize there are three types of projects – Directives, Problems, and Opportunities. Directives can be imposed by management (for example, to improve the image of a company), by government (like the Dodd-Frank Act to meet financial compliance regulations), and/or by external stimulus. Problems are unwanted situations that prevent an organization from attaining its goals. A company might face upgrading outdated hardware with faster processors, so users can get information in a timelier manner to do their work. Outdated equipment is a typical problem that needs a solution. Most organizations find it’s easier to get project approval and funding to address directives and problems. Regardless, financial analyses should still be done on these typical “sure projects,” so you can find out how much is left over in your budget for opportunity projects. An example of an opportunity project would be creating a new product that could be the future of your business. Let’s take a look at the different ways of performing project financial analyses on these types of mentioned projects. Performing Financial Analyses on Potential Projects Payback Capital budgeting refers to the period of time required for the return on the entire investment if the returns are evenly distributed over the years with little or no salvage value. Assume an investment of $500,000 is expected to produce annual returns of $100,000 for ten years. The Payback (PB) period for the investment to be recovered would be five years. The ratio of the investment to the annual return is 5:1. Expressed in another way, the unadjusted rate of return is 20%, can could be described as follows: the $100,000 returns is divided by the $500,000 investment, which equals a 20% rate of return which is a good annual return. As anyone should see, the math is simple to follow, but the payback period has some drawbacks. For example, it ignores cash flows after the payback period ends and ignores the time value of money. Net Present Value (keep reading!) does take into account the time value of money (the net cash flows at different points in time), which gives a more accurate picture of financial performance. Small companies often focus on PB because they like to recoup their investments in a year or two. Of course, it is always ideal to get a quick payback, but larger firms are less interested in using PB because they can afford to wait for longer paybacks and cash flows. Net Present Value Net Present Value (NPV) is one of the most widely used financial attributes because it measures the financial return of an investment taking into account external factors like inflation, investment risk, and the cost of borrowing money. See Figure 1.1 which shows the NPV for two projects. Following are a few notes explaining what you’re seeing: The Excel financial formula for NPV (i.e., Discount Rate and values) is shown. Note: Excel’s NPV function is not perfect and has some quirks, so the NPV numbers you see are close, but not exactly the correct number. The Discount Rate (cell B1) is the act of discounting future cash flows. It answers the question of how much money would have to be invested currently, at a given rate of return (let’s say 10%), to yield the forecasted cash flow, at its future date. Notice the cash flow totals ($3,000) are the same for both projects, but NPVs are not the same. This is due to the time value of money. Return on Investment Since some executives prefer to see an annual return per project, they might look at the profitability index or Return on Investment (ROI), which is the NPV divided by the initial investment or cost to get the best combination of projects. This ratio basically gives you the biggest bang for your buck for each project, and the higher the profitability index, the better. ROI could be negative or positive. A high positive ROI is outstanding. Figure 1.2 shows seven highlighted projects using the highest profit index. Since many executives like to see the profit index as a percentage, I’ve show the index and the index multiplied by 100% in the last column. Internal Rate of Return You may want to determine what Discount Rate (see Figure 1.1) will yield a zero NPV for your particular project. A higher Internal Rate of Return (IRR) means that the investment is less exposed to risks that could corrode the value of the investment. The IRR is found through trial and error. Again, Excel’s IRR function is not perfect and has some quirks, so the IRR numbers you see are close to the correct number although not exact. In my experience with many different companies and industries, IRR is the biggest driver behind making financial decisions for most projects. Recent surveys indicate most executives prefer IRR over NPV because they find it easier to compare investments of different sizes in terms of percentage rates of return, rather than by the dollars shown in NPV analysis. However, some executives and most academics feel NPV remains the more accurate reflection of value to business. The following figure shows an IRR (or Discount Rate) of .181781059. This is approximately 18% of Project 2’s cash flow from Figure 1.1. If the Discount Rate in Figure 1.1 was changed to 18%, then the NPV for Project 2 would be close to zero. Using a Weighted Scoring Model A weighted scoring model is a good tool because it provides an organized process for selecting projects based on many criterions. Each organization has to assign weights to each criterion they choose based on importance. Over time and with experience, your company may update the criterions it uses (for example, you’ll begin to use multiple financial measures like PB, NPV, and/or IRR). Figure 1.4 provides an example of a weighted scoring model used to evaluate three different projects. The weighted score is calculated by multiplying the weight % for each criterion by its score and adding up the results. For example, you calculate the weighted score for the highest rated project (2) as: (10% * 90) + (10% * 70) + (10% * 90) + (5% * 50) + (15% * 90) + (50% * 90) = 86. There are many other things you can do with this model like stating acceptable thresholds for a specific criterion. For example, you may choose to not accept a project that has a score of less than 50 for availability of resources. As you can see, weighted scoring model can be an important tool in aiding your organization in project selection decisions. Summary A balance scorecard is a strategic planning and management system that helps organizations align business activities to their strategy and goals. This scorecard has evolved over time, and the Gartner Group estimates that over half of large U.S. Organizations use this approach. You can find several examples of balanced scorecards from different manufacturing companies like Shat-R-Shield. I hope you have learned that performing financial analyses on projects can actually be “No Pain, All Gain.”
Integrated Change Control
Very few projects run exactly to plan. This happens for a number of reasons (one example is scope creep). The bottom line is that you should expect changes to happen! Integrated change control (ICC) is the process of reviewing all change requests, approving changes, and managing changes to deliverables with documentation. It also involves communicating decisions that have been made. ICC consists of many overlapping areas, such as change management, project management, configuration management (CM), and the change control board (CCB). See Figure 1.1 below. Let’s look at each area: Change Management: Within information technology (IT) systems and quality managing systems (QMS) is a strategy and process used to insure that changes to a product or service are introduced in a controlled and contained way. This ensures that any negative effects of a change are minimized. The core of ICC is establishing the CCB, thus documenting the extent of its’ authority. Therefore, change management will impact the decisions made by the CCB and is a key factor to reducing failures and having successful project management. Project Management occurs when project managers (PMs) strive to meet the specific scope, time, cost, and quality goals of their baselined projects. In doing so, they use knowledge, skills, tools, and techniques to meet their project requirements. The PM notifies everyone affected by their approved CCB changes in a timely manner. Configuration Management (CM) involves identifying and controlling the functional and physical design compositions of the product or service. Common document control software used by CM is Information Technology Infrastructure Library (ITIL), which contains a set of practices on aligning its’ services with the needs of the business. It boils down to figuring what you have, controlling who can make changes, and keeping a record of the changes made. Change Control Board (CCB): The CCB consists of a formal group of people (i.e., key stakeholders and subject matter experts/PMs, as needed) who are responsible for reviewing, approving, rejecting, and/or deferring changes within a project. The key functions of a CCB (see Figure 1.2) are to provide guidelines for preparing project change requests (PCRs or CRs), assessment/analyzing CRs, and managing the implementation of approved changes. Typically in large organizations, CCB meetings are scheduled on a weekly basis (these meetings may be done by conference call). It is the responsibility of the change manager to send out the CRs for discussion prior to the meetings. Each participant has the chance to review proposed changes and gather any relevant information before the scheduled meeting. During a typical CCB meeting, the change proposals are reviewed and a “go” or “no go” decision is made for each proposal. The approved CRs are then prioritized for scheduling purposes because there is usually a limit on available resources and money. Keep in mind that maintaining quality is an important part of this decision making process. Here are some guidelines to follow when conducting CCB meetings: When you have a large number of small changes, it may be more efficient to bundle them together into one CR package, so that everyone’s time is managed more effectively. Keep in mind, some changes can likely be made at zero or near zero cost. Trigger automatic approval for CRs that have little or no effect on schedule, cost, or scope with a set threshold (for example, those at a $500 or below cost). Have a special process in place to handle emergency CRs (for example, a backup disaster recovery system that stopped working). These are items that need to be addressed immediately. With a process for handling such issues, changes can be put into place before the next scheduled CCB meeting. Check to see if there are any relationships between the submitted CRs and ones already being worked on. A lot of different outcomes may happen depending on the scenario, and you want to avoid duplication. For example, combining CRs, rescheduling the work, stopping work on an approved CR, or not approving a submitted CR because of its’ being a duplicate. It’s important to discuss the risk/rewards of each CR. Analyze the impact both to the project and to the organization. Don’t be hesitant about saying “No” to CRs in order to promote a steadier work environment and ensure that only critical CRs are implemented. Furthermore, if a CR is incomplete or not worth the time to analyze, it should be rejected immediately. Change process documentation (for example, CR Submission Forms or CR Tracking Documents) is important because it helps to manage the flow of requests through the process. These forms can be easily generated in Microsoft Word or Excel. In the long run you would be better off using Excel because it would be easier to track changes and display selected data using the Sort and/or Filter features. Compile a list of lessons learned after completion and final acceptance of the change. This includes input from the person initiating the CR and the affected customers. This information could be invaluable for future projects. Configuration Management in Integrated Change Control A big part of the documentation control process is CM where the flow of product and project documents are controlled in the CM libraries filed by documentation type with version control references. The ICC process utilizes CM for the supporting documentation (for example, functional and physical characteristics of the project’s products) as it moves through the decision process. ITIL is a broad set of references that explain effective ways to handle many aspects of IT support and delivery, including asset and configuration management, change management, release management, and problem management. Also the CM repository can be used for Incident Management (IM). An incident is an unplanned event that could lead to a loss or a disruption of running a business. A few examples: Cybersecurity threats Supply chain disruption Brand reputation attacks on social medium Product quality issues Workplace violence Terrorist activities Data breach Natural disasters Software tools such as ServiceNow and BMC Remedy have been widely adopted and integrated with other systems (especially ITIL) to manage problem resolution. BMC Remedy automates standard ITIL processes out of the box. Extensive configuration options enable you to tailor chosen applications to the needs of your organization. This is based on a response plan that defines what constitutes an incident and delivers step-by step procedures for each defined incident. If you want more information on this topic, visit the Institute of Configuration Management website (www.icmhq.com). Summary Successful change management depends on identifying, evaluating, and managing change events in a project and eventually in the end user environment. The ICC process or components are controlled by the CCB or steering committee, and thus supported by a formal workflow process and appropriate communication technology. The key functions of CCB are to provide guidelines for preparing CRs, evaluating them, and managing the implementation of the approved changes. Another good idea is for the PM to create custom field(s) in Microsoft Project to flag change request tasks, which later can be filtered to only view the tasks with the change request tag. For example, the custom flag field could have the CR number or date of the approved CR. Better still, you could have two custom flag fields – one for CR number and one for date approved. PMs should be involved in managing the project changes by delegating the work and/or being part of the team making the changes. Keep in mind, CRs will more than likely change the original critical path (Note: Microsoft Project will show the critical path using the Filter feature), resulting in a new estimated completion date for the project. Another key factor in change control is for the PM to use written and oral reports to notify everyone affected by a change in a timely manner. Some major approved changes may mean rewriting the project’s charter and/or scope statement. Remember, good project communication is always a critical key to successful projects.
Outsourcing Done Wrong
Some of the Worst Practices that Guarantee your Time and Money Won’t Be Well Spent An outsourcing project, especially in Information Technology (IT), can be a long and winding road studded with sweet spots and painful pitfalls. There are numerous opportunities to veer off course. At any point, companies can make irreparable errors, including forgetting proper due diligence up front, mid-project cost cutting at the expense of quality, and/or insufficient focus on knowledge transfer and training. These mistakes can ultimately cause delayed completion dates, as well as increased costs and scope creep. If you are eager to bumble your next outsourcing effort, here’s ten things to do (or Don’ts), which will put you on the fast track to failure. I’ll go into the reasons why to do the opposite of each, and we’ll see how to make the most of outsourcing without the mistakes. 1. Don’t evaluate the business case for outsourcing. Any methodology should include strategic reasons for it. In the case of outsourcing, you may be wishing to improve business focus, gain access to novel capabilities, accelerate reengineering efforts, and share or transfer risks. Before you get started with any outsourcing effort, you should look at your business reasons for it. For example, if you were buying a specific mainframe to be used for five years, you could: Estimate your up-front costs (hardware, software, and one-time costs) Estimate your new operating costs (such as maintenance) Estimate your savings (such as eliminating positions or less overhead) Estimate your increase revenue Calculate cash out (A + B) Calculate cash in (C + D) Calculate net cash flow (F – E) In this way (see Table 1.1), you can rank different projects, be they current or proposed, and get a solid picture of the best investment for your organization. 2. Don’t identify all your costs. Not identifying all the costs is the problem that pops up most often in outsourcing agreements. If you want a successful outcome, do all you can to avoid the following mistakes: Having a complex solution versus a simple one. Underestimating the project’s scope. Underestimating the costs of software and hardware (one time and recurring). Underestimating the quantity of software and hardware. Underestimating the delivery dates of software and hardware. Underestimating licensing and maintenance support coverage (one time and recurring). Not considering the inventory of new equipment and the disposal of old equipment. Forgetting about supplies and spare parts. Forgetting to supply appropriate facilities for the outsourcers. Incorrectly expecting free work from one of your main vendors. Forgetting about overtime services. Losing key resources and undertraining replacements. Having key resources working on multiple projects. Working with a long-distance outsourcer. Having no risk management plan. Having no recovery plan. If you haven’t taken a long look at what it really costs to develop a particular project in-house, as compared to outsourcing it, the supposed savings of sending work to a consultant or overseas service provider may spontaneously combust, leaving you with insufficient funds and an incomplete project. 3. Don’t worry about the big picture for deadlines. If other projects overlap your planned outsourcing project, are you prepared? Internal project schedules must be coordinated to eliminate any duplicate efforts, unknown dependent activities, out-of-sequence tasks, and payment confusions. Other potential obstacles include special promotions, the opening or closing of facilities, and moratorium dates that conflict with holidays, payroll processing, backup periods, annual disaster recovery (DR) testing, and financial closings. 4. Don’t analyze stakeholder and sponsor commitments. It happens all too often that stakeholders don’t see eye-to-eye or have different agendas, whether due to interpersonal, geographic, or cultural differences. Perhaps the project’s sponsor isn’t truly committed to the project and hinders progress by not making timely key decisions to keep it moving. Or maybe some client teams and management just don’t like conceding control to outsiders. It’s crucial to research and document all stakeholder needs and their competing obligations before you outsource the project. If you don’t, you’ll run the risk of having it torpedoed mid-course. 5. Don’t write down your conditions of satisfaction. I have worked on projects that met all the conditions of the contract (as well as being on time and within budget), and they still weren’t considered successful by the client. Why? Because the conditions of satisfaction (COS) weren’t defined or passed on to the outsourcer before the project started. A smart outsourcer knows this, and will help you develop your COS. There are usually some elements of “knowledge transfer” in the COS, and the intent of this is to ensure that intellectual property isn’t lost to the organization at the end of the contract. However, anyone who has been a part of knowledge transfer activities (see Figure 1.2); whether from the outsourcer or client perspective, will know these elements are rarely robust enough to be effective. Recognize that it’s in the outsourcer’s interest to retain knowledge in order to have ongoing revenue in the forms of support work. This is not an easy endeavor, but the client must work on developing processes and accommodating tools to effectively and efficiently collect the transferred knowledge from the outsourcer before they leave. Over and above the COS related to intelligent property, there can be other issues when dealing with local and foreign vendors. The legal system of some countries doesn’t offer intelligent property protection. This disparity allows the vendor to extract the client’s intelligent property and could result in the outsourcer to become a competitor and/or leak the knowledge to others. This has happened many times in the past with U.S. industries (i.e., computers and electronics). Intelligent property and internal technical information must be carefully controlled by the client, so there is not a loss of competitive advantage. 6. Don’t manage your relationship with the outsourcer. Most companies underestimate their own management requirements when it comes to outsourcing. What is the way around this? Have the outsourcer develop a communications plan at the start of the project to be approved by you. The plan should: Describe all stakeholders’ communication needs. Define how stakeholders will be kept informed. Identify the communication paths between project teams and stakeholders. Describe standards used for deliverables and repository information. Remember, you can’t put an outsourcing agreement in place and then walk away. Make sure that you manage the outsourcers in the same way that you would your own team. Use governance and oversight to keep an eye on what they are doing on your behalf. Track their progress regularly. If something goes wrong, it’s your project that will suffer, so keep a close eye on the work that is going on. This isn’t about micromanaging, but more about making sure that your goals are met. You wouldn’t expect to give someone else a task and hefty salary, and then never check up on them, would you? No! So, don’t do it with third parties either. All outsourcing arrangements should be based on the concept of “trust, but validate.” When working with outsourcers, you should want to build good relationships through communication, shared goals, ideas, and joint proposals. By doing this, you will obtain greater opportunities to see their workmanship and know-how in action. Another benefit of having a good relationship is that you might find the same outsourcers useful again for future projects! 7. Don’t be prepared. I have worked on outsourcing assignments in which the client wasn’t physically prepared for us (for example, no office space or facilities had been designated). This resulted in a lot of scrambling around. I have also seen clients who didn’t implement a virtual private network to support the requirements of the outsourced project. Furthermore, I have seen clients who didn’t implement the agreed-upon technology changes that were vital to fast progress on the new product. Listen to the “Boy Scouts” and make sure you have your site and your hardware ready for your consultants or an overseas offshore service provider. An element of outsourcing that very few organizations consider is the impact it can have on the client organization’s own processes. Organizations that historically conduct their own projects, or who bring individual contractors into the organization when required, can work with their own internal methodology and not be too concerned about how well aligned the approach is with anyone else. When it comes to outsourcing, that logic doesn’t apply. Not only is there a need to be able to explain the project execution approach to whomever lacks the expertise of how the client operates, but there is likely to be a need for integrating that approach with the vendor’s processes. Even more fundamental, internal processes may not exist for working with a vendor. Evaluate reviews, hand-offs, approvals, etc. 8. Don’t define your responsibilities. In my experience, the client is always quick to define the outsourcer’s responsibilities, but slow in defining their own, which includes assigning roles. This isn’t just a handoff! The degree of discipline that the client’s leadership exercises can make or break a project. To succeed, you must meet your own schedule commitments (supply appropriate equipment and people). A good tool to use is RACI Charting. This serves as an effective means of analyzing and assigning roles and responsibilities. It correlates functional roles or individuals to their level of participation in an activity by assigning codes for Responsibility, Accountability, and Communication Interfaces. This simple technique can be used any time the span of control for a process needs to be determined or developed. It is a quick means of bringing redundancies and misunderstandings to light, so that better communications can occur. Steps to complete a RACI chart include: Selecting a business process to be analyzed. Listing all of the activities associated with that process in the left-hand column of the chart. Identifying all functional roles associated with the process and listing them in the top row on the chart. Establishing participation for each activity, for all roles, by assigning codes as described below. R (Responsible) – The individual working on the activity (the doer). A (Accountable) – The individual with the yes/no authority, approval, or veto power. (Note: If two or more A’s exist, this could be a sign of problems.) C (Consult) – The individual who should be consulted prior to action; two-way communication occurs. I (Inform) – The individual who receives one-way communication and will use the information or take subsequent action. The following is a simple example of a RACI Chart that depicts what happens when a client with a computer problem outsources its in-house Help Desk to IBM. Expect the outsourcing company to outline your responsibilities in a contract or statement of work (SOW). If it doesn’t, or does a poor job in defining what it expects of you, look for a firm that knows what it’s doing. When looking at the outsourcer’s contract, look for dangerous words that should be viewed with caution. The bottom line is, are these words or descriptions really achievable? If not, there could be legal problems. For example, words ending in “ly” (fully, completely, and satisfactorily) have different interpretations in a court of law. Other dangerous words could include best efforts, best estimate, and increase, lowest, greatest, earliest, latest, optimum, minimum, and maximum. The last thing you want is to have improper or unrealistic expectations about deliverables. 9. Don’t free up internal resources to work on the new project. A parsimonious attitude toward personnel will doom your project from the start, but you can’t toss unlimited resources around either. Before the services begin, you need to designate a PM to work with the outsourcer’s PM. Your PM manages many of your responsibilities as a client, acting as a liaison between your team and the outsourcer’s project team. The PM provides data and makes decisions in a timely manner, ensures that the appropriate personnel are available to the outsourcer when needed, participates in project status meetings, helps resolve problems and escalates issues as necessary, and directs the project implementation schedule along with the outsourcer’s PM. Assigning a PM to act as the point person is not all! You may also need to deal with other personnel issues, such as hiring new people or using subcontractors to match required skills for the project, ramping up and rolling off staffing, training and learning curves, planning for holidays and vacations, and choosing personnel to commit to multiple projects. Other things that may pop up are employees resisting the different processes and methods used in your outsourcing program. This is when you especially need senior management’s commitment and support to ease the resistance. 10. Don’t select an outsourcer who understands your business. Unfortunately, many firms don’t bother spending time and energy to select the best outsourcer, and most come to regret that oversight. This is a big investment decision, and you will have time to live with it during and after the project. First, seek bids from at least two or three outsourcers. Make sure they are qualified, have references, and check out as reliable. Learn about the people the outsourcer’s uses: experience, locations, and subcontractors. Don’t assume anything when reviewing proposals. When in doubt, ask questions. Don’t base your final decision solely on the lowest bidder. And, remember to always get legal counsel before signing anything. Summary I have taken the above ten “Don’ts” and converted them into ten questions (with descriptions) for outsourcing success. There are numerous opportunities to veer off course. According to Eric Door, senior research director at the Hackett Group, an Atlanta-based strategic advisory firm, at any point, companies can make irreparable errors, including inadequate due diligence up front, cost cutting at the expense of quality, and insufficient focus on knowledge transfer and training. Use these ten questions (Table 1.3) to help ensure your success. Fill in numbers in the column labeled “Your Project,” and then add them up to get your total and see what it means. As you can see, managing outsourced projects is quite different from managing “in-house” projects. An outsourced scenario requires excellent skills, knowledge, and paying extra attention to detail. Managing outsourcing with care and forethought can build a thriving partnership and help insure future outsourcing projects will be successful. Avoid the mentioned outsourcing mistakes, and your organization will have a greater chance for success. Before I close, I wanted to point out that outsourcing projects is really about vendor management, and rarely do we ever read anything from the vendor’s point of view when looking at this process. The following are some key points a good vendor will observe and/or do. Don’t forget to evaluate the following points when choosing your next outsourcer partner: If the client-vendor relationship didn’t exist before, a Master Service Agreement (MSA) is usually drafted by the vendor to tie the knot of the new partnership. It should be followed by the statement of work (SOW). Vendors typically respond to the client’s request for proposal (RFP) by doing research, pricing their work, and presenting a proposal to the client. Good vendors usually try to keep it simple. You don’t want to work with a vendor who tries to solve too many problems or over-complicates the solution. If the vendor does a good job, the client usually comes back for a “Phase 2” to address remaining problems or take a project further. This step usually opens the door for a long-term relationship. There is always more than one way to solve a given problem, and you must be aware of this. Each approach will have pros and cons. The vendor should come with corresponding costs and savings tailored to the client’s risk desire and price-to-performance attraction. The vendor should be aware that the client’s final decision is made by human beings and not by automated systems. They should also exhibit an understanding that the client’s technology/architecture team (those assessing the vendor’s proposal) may be resistant to change. Unfortunately, this is true of most humans! If the vendor aligns its’ core strengths and values with the client’s underlying needs, they stand a better chance of winning the deal and possibly becoming a real business partner!