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.
Managing Multiple Projects
There have been times throughout my career that I was given a “project,” but soon realized that it was really a group of related projects or a portfolio. In MS Project, a master project (or consolidated project) is the easiest way to work with a group of connected, large projects (or sub-projects) at the same time. You can create a master file, and then insert the sub-project files into it to consolidate them into one huge file. If you open and update a sub-project, updates will flow through to the master file and vice-versa. Some of the benefits (or powerful capabilities) of having a master file are: It’s easier to see the big picture when viewing all sub-projects in a single view or report. It’s easier to link tasks (or relationships) between sub-projects to show dependencies. It’s easier to add new tasks and/or delete unnecessary tasks. It’s easier to see if there are any resource sharing conflicts. You can filter, sort, and group data from all related projects. You can roll up information into higher levels of management. You will see the critical path for the entire master file (not by sub-project), which will give you a better perspective for managing your entire project or portfolio. Preparing Subprojects for the Master Project File To create a master file that does all I listed above, there will be a few minutes of work to do for each subproject, so that things will sync up correctly within the master project file. Let’s say we have three large subprojects that we want to combine into a master file. When we insert the subproject files into the master file, each subproject will start off with ID number 1 and so on, which means that if you leave as is, you will have three tasks with the same ID number. Of course, this is potentially confusing especially when you are filtering, sorting, and grouping tasks. To avoid this, ignore the ID numbers entirely, and refer to the WBS code with a project code prefix to individually identify every task. This approach will allow you to identify what subproject each task belongs to. You need to come up with your own unique project code prefix for each subproject and make the changes in the subproject files before inserting them in the master file. I believe in keeping things simple. For the first subproject, I will use the code prefix X, the second one will be Y, and the third one will be Z. To start this process, I will open subproject X. On the Project tab, navigate to the Properties section, select WBS, and Define Code. Then, enter “X” in the Project Code Prefix field, and select Numbers (ordered) under the Code mask. Finalize by clicking OK (see Table 1). Repeat this process for subprojects Y and Z. Out of the three subprojects, select the one with the earliest Start date, and update the other two subprojects with the same Start date (this field is found in the Project tab’s Properties section under Project Information). This Start date will obviously be the Start date for the master file. Odds are that the work calendars are the same for each subproject, but it doesn’t hurt to double check. Go to the Project tab’s Properties section, and select Change Working Time. It is more than likely that you will be using the Standard calendar. Creating a New Master Project Upon opening your new master file, you will be in the Gantt Chart table view. I would recommend you begin by inserting two new columns: WBS before the Task Name column and Subproject File after the Task Name column. When you insert the subproject file, the full path to the subproject will be shown. Do not waste valuable space by widening the column to see the entire path. Instead, when needed, just hoover your cursor over the cell to see the full path. Over time, you may even choose to hide this column to save space. The next step is to highlight the Subproject cell in line 1, and then, on the Project tab, select Subproject Insert. Locate subproject X and click Insert. Do the same on the second line for subproject Y, and on the third line for subproject Z. Each inserted subproject appears as a collapsed summary task, with an inserted project indicator in the Indicators column. See Table 2. To see the details of the inserted three subprojects, highlight the three lines (or click in the upper left-hand corner of the Gantt Chart table). Go to the View tab’s Data section and select Outline and All Subtasks. MS Project will expand all the tasks in the three subprojects, and you will immediately see the usual WBS numbering system preceded with an X, Y, or Z as was defined previously. Next, you will need to setup some dependencies between the plans or subprojects, so the entire schedule will be in chronological order. To do this, select the task you want to make the predecessor task while also selecting the task (using the Ctrl key) that you want to be the successor task. On the Task tab’s Schedule section, select Link The Selected Tasks (Ctrl+F2). The two tasks will be linked with a finish-to-start relationship. Make other necessary updates and save your master project. You will be ready to begin manipulating data and working with the various reports. Summary and another Possible Scenario Up until this point, my article has discussed the advantages of using a master plan for huge projects (upgrading Oracle financial systems to the latest version, for example). We’ve shown how to generate one by inserting subprojects into a master file, which is your typical scenario for using a master plan. However, there is another possible scenario which is less used, but some project managers might want to utilize. Let’s say you spend your time on ten small, unrelated projects. Instead of juggling back and forth between plans, you could insert all of them into a master project to make updating easier. Obviously, some things will be different because you are not really trying to consolidate anything. In this scenario, for example, you probably will have no links between the projects, and you will want to see the critical path for each individual project and not the entire master file. If you go this route, there are a few things to note. You’ll most likely want to change the critical path default setting from the entire plan to calculate individual project critical paths. To do this, choose File > Options > Schedule. Scroll down until you see “Calculation options for this project,” and turn off the “Inserted projects are calculated like summary tasks” selection. Then, click OK. Remember, you can still produce consolidated views or reports for all your projects. The bottom line is that you learn as you go! Please share your experiences using master projects. Have you ever created a resource pool to be used for your master plan or used the Enterprise resource pool in Project Server? Can you share any other benefits of using master projects that were not mentioned?
Merging Project By-Products
Imagine putting a fifty-piece puzzle together that depicts an overview of a typical project. Each puzzle piece is like an artifact or one of the tangible by-products developed during the timeline of a project. The center piece is the project plan, and other pieces that could snap into the center piece may be the project’s charter, a communications plan, and/or a staffing management plan. Those pieces would have other pieces snapped into them like the checklist estimation, a risk assessment worksheet, contacts, lessons learned, and so on until all the pieces interlock into a completed puzzle. Managing projects means keeping track of information stored in different places and from different types of files. It would be more efficient if most of this inter-related data was accessible through one central project plan, so that the project manager and all team members had one place to go to find information! Let’s look at some different ways project artifacts can become easily accessible through MS Project. Nice Notes In the Task view, double-click on a task to see its Task Information dialog box and to select the Notes tab. You can copy data from another program and paste it into this area, as needed. A good example of this is shown below in Figure 1. Notice that two lines were copied from an Excel spreadsheet and pasted into the Notes area preceded by a text line. The same can be done within the Resource Notes and Assignment Notes fields. Once you add a note to a task, the task’s Indicator cell (under its “I” – column header) displays a sticky note icon (this also applies to Resource Notes and Assignment Notes). To see a note’s contents, hoover your mouse over the icon. You can also link and embed objects in the mentioned notes areas. This is covered in more depth below. Linking Linking a file means that the data remains in the source file, but can be seen in the destination file or within, for the sake of example, Project. Linked objects will be updated automatically if the recipient(s) have access to the externally linked files. If this is not the case, the user will see an error message instead. When you double-click a linked object, the source program starts, and you can update said links if needed. To develop our Note link, we would select the last dialog box from Figure 1 (under “Notes:” and above the notes area), which is the Insert Object button. We then see something similar as is displayed in Figure 2 below. Notice that, by default, Create from File was chosen and the location of the chosen PDF file selected. Be sure that the Link and Display As Icon boxes are checked. If you are doing this for the first time, read the Result definition. When you’ve inserted your link, click OK to see the outcome (as shown in Figure 3). As mentioned, double-click the linked object to open it. Other types of links include that of internal dependency between tasks in the same project plan and external dependency (or cross-project dependency) of tasks in different projects. Embedding Embedding is similar to the above mentioned copying function, but it’s a copy of the source file and you won’t be seeing updates made on the original. When you work with entire files, the linking and embedding steps are almost identical. The exception is that the Link box will not be checked (see Figure 4). Embedding objects is a good method to use when you have a wide distribution of people that don’t have access to your files. Hyperlinks Project has another type of link. It’s called a hyperlink, and sometimes referred to as a live link or hot link (for example, you can link to an Excel spreadsheet, a Word document, a web page, an email address, etc.) Note that you can only have one hyperlink for each task, resource, or assignment. If needed, you can add additional hyperlinks or links in the previously mentioned Notes areas. To create a hyperlink, right-click the task, resource, or assignment, and then choose the last item listed on the shortcut menu (hyperlink or link). Select the type of data you want to Link To, and then select the folder you want under the Look in section, select your file, and click OK. Figure 5 shows the Insert Hyperlink dialog box. When you use this function, the Indicator cell displays a globe with links of a chain. Hoover your mouse over it to see the contents, and click it to open the hyperlink file with its associated program. If you don’t have the Indicator column showing, right-click the task, resource, or assignment. From the shortcut menu, select the last item (hyperlink or link) and then Open. There are many ways of viewing all the hyperlinks within a plan. You can insert the Indicators or Hyperlink columns or go to the View tab’s Data section. From the View tab’s Data section, select Tables > More Tables > Hyperlink (default is Task, but you can select Resource), and then finally, Apply. The generated table will show all the Hyperlinks with their addresses. If a task or resource has no associated hyperlinks, only their names will be displayed. Summary I have shown several ways of linking/embedding project by-products within your project plan. Hopefully, you can try these methods and will be one step closer to having a main source of information for your projects. A cornerstone for doing this is using the Notes area. You can also use Notes as a mini-project diary (or electronic notebook) of events that are happening in your project. For example, you could have a dated comment that a person gave two weeks’ notice and is going to be replaced with the Resource Notes area. For WBS 1, you could embed the project’s charter, and for a Lessons Learned task, you could link the appropriate document to be updated throughout the life of your project. What are some of the ways you are using the mentioned tools for putting more information into your project plan? For example, you may be embedding partial files or a Visio workflow diagram in the Gantt Chart timescale.
Starting a PMO
Learning to Walk Before You Start Running PMI describes the Project Management Office (PMO) as a strategic driver for organizational excellence. The PMO seeks to enhance the practices of execution management, organizational governance, and strategic change leadership. Because of differences in organizational structures, power and politics, and culture, it would be extremely rare to ever find two PMOs that look the same. For example, if you had three American companies in the same business of manufacturing motorcycle tires and each had 4,000 employees which included 100 IT people, their PMOs would still be different. Company A might not have a PMO, company B could have a PMO where the project managers (PMs) do not report to the PMO, and Company C could have a mature PMO where the PMs report to the PMO. This article is meant to give some guidance for starting a PMO and eventually growing into a Strategic PMO (SPMO). Remember, People + Process = Success. Assessing Your Current Condition Before you really start, it’s important to understand your organizational structure because it will affect what type of PMO you will eventually have. Table 1 shows the six types of organizational structures with short descriptions. Whatever your organization type is, you should be looking at the benefits and challenges your organization has, so you can capitalize on the benefits and work on diminishing challenges as you move forward. The next step is to find your baseline. The questions to ask are: How many projects are underway and what is their current status? Are failing projects or extremely risky projects being cancelled? If not, why? What new project proposals are coming down the pipeline? Do you have any redundant or overlapping projects? How is this competence being realistically tracked and documented? Do any of the projects link back to corporate strategy or goals? Do you use a project management methodology and is it “institutionalized?” If not, do you have any processes in place that could become part of a new project management methodology for your organization to use? After looking at all of this, you should have a good idea of where you are starting and then be able to compare your current baseline to an existing capability maturity model (CCM or Table 2) to determine where your organization stands in terms of generally accepted process standards. After you find your organization’s maturity level, the next choice is what amount of change your organization is willing to accept. It’s crucial to keep your eye on the prize. That is, it is better to run projects that have more repeatable processes. From my experience as a PM, I can verify that the lower the level of maturity, the greater the failure rate on projects. Project management must exist as a repeatable, quantifiable process (found on Levels 3 – 5 of the CMM table) for there to be any real chance of consistently bringing projects in on time, within budget, and according to customer expectations. The major causes of why projects fail are not the specifics of what went wrong, but rather the lack of policies, processes, and procedures. There are many challenges in setting up a PMO, but the biggest ones are underestimating the effort and complexity involved and instilling cultural change throughout the organization. Not an easy thing to do! You must have senior management backing and on-going support to start up a PMO, and most importantly, you must understand that this will take time. It starts with small steps, short-term successes, and adding value as quickly as possible. I have organizations with a history of project failures decide to start-up a PMO as a quick “silver-bullet” solution hoping to fix an on-going situation. After two years, the PMO most likely dissolves. In most of these cases, senior management was not sincere in the backing of their PMO (OK – it started out as a zombie PMO that lacked strategy, vision, and mission), and/or the organization didn’t understand that the growth and maturity level of a PMO is like a bottle of fine wine (it gets better over time). This common error dooms many PMOs from the beginning because management is disappointed not getting quick results. Dissolving a PMO may show that senior management doesn’t understand or respect the value a PM brings. They may also promote a highly technical person to the position of PM. I call this the “Halo Effect” because usually the technical person knows very little about project management or seeing the big picture (for example, all the inputs and outputs). They may be a poor communicator who eventually ends up losing their “shine.” One’s technical ability is a meager indicator of their project management ability, yet many organizations still don’t have formal training and/or mentoring processes in place for PMs to have their work evaluated. Some studies (i.e., US National Bureau of Economic Research) suggest companies should promote based on traits of good managers, rather than as a reward for good employment. This is an unfortunate situation and is telling of an organization. If there is a high rate of leadership turnover, it will negatively impact the value and stability of the PMO. The importance of a good PMO and consistent leadership can’t be overstated! Beginning a PMO Beginning a PMO is not an overnight event. This process requires a total commitment by the entire organization. It must be recognized that it takes years for a PMO to mature, have repeatable processes, and to fully add value to the overall organization. If management is expecting quick results, they are often disappointed. For start-up purposes, it would be wise to have a PMO Charter document that describes its’ vision, mission, goals, and objectives. Furthermore, this document would describe the roles and the contributions the PMO is planning on making. In a way, this is a kind of press release that should be distributed to the organization, so everyone is on the same page and there are no surprises. If you have no formal project management methodology for developing projects, then you need to work on one. A methodology should be viewed as a living organism that constantly needs to be reviewed and updated. Furthermore, the methodology needs to be scalable (or flexible) for different sized projects and/or complexity. For example, if you had a large project plan that has 3,000 tasks and another project that has 300 tasks, then the smaller project would have fewer mandatory tasks, less gate approvals, and less scrutiny. It’s important that the PMs “buy in” to the new methodology and that everyone starts using it, so there is no confusion or miscommunication within the organization. Maturing a PMO into a SPMO The SPMO (see Table 2/Levels 3 – 5) is created to assist in making sure organizational projects are done at the right time, with the right tools and templates, and that they contribute to the organization’s strategic plans. Typically, in the early levels (Initial or Repeatable) of the PMO, the PMO manager usually reports to middle management within a large IT department or to the Chief Information Officer (CIO) within a smaller IT organization. As a PMO starts maturing into a SPMO, its leader (director or VP level manager) should sit with other senior executives within the organization. This position of leadership is responsible for overseeing corporate wide distribution and allocation on all projects. The SPMO leader will have several critical roles to fill. They must ensure that the project management process runs well while always looking to improve it. Some of the most critical responsibilities of the SPMO leader are: Resource management: The process of managing the overall project resource pool is one of the most valuable aspects of the SPMO. Resource management is one of the most complex challenges for both the PM and PMO/SPMO. Many would consider failures in this area as the Achilles’ heel of project management. It’s important to successfully link appropriate resources to project needs. Allocating the right resources to projects includes staffing with the right people and contractors (when needed), training, and mentoring. Prioritizing projects to align with strategic plans: Historically, most IT departments have spent approximately 75% of their annual budget on running their business, which included supporting their infrastructure and paying their employees. This means the other 25% of their budget was mostly spent on projects that had nothing to do with corporate strategy. This raises the question, why were they working on these projects at all? Most new projects should support the organization’s strategic plans, which require an integrative process for prioritizing projects. SPMO Steering committee: Besides the SPMO leader, the governance committee should consist of senior management from each of the businesses and subject matter experts (SMEs) when expertise is needed for selecting and monitoring strategic and nonstrategic projects. The steering committee should define what projects meet short-term and long-term strategic goals. They should also prioritize these projects since each organization has limited resources. One of the harder things the committee must do is kill (or put on hold) a project that is underway that may not be developing as planned. This should not be looked at as a failure, but seen as an opportunity to reallocate resources to more important projects. Summary Almost 75% of PMOs fall below Level 3 on Table 2, according to Gartner Research, a prestigious consulting firm. Moving from a PMO to a SPMO is a very difficult journey. An organization must invest in their people, as well as in time and money to become a success. That said, according to further Gartner Research, “IT organizations that establish enterprise standards for project management, including a SPMO with suitable governance, will experience half the project cost overruns, delays, and cancellations of those that fail to so.” Ultimately this means that you will be moving your organization from its present position to a future strategic position in order to exploit new products and markets in this fast-changing world. To be successful, SPMOs need to focus on customer value and using the best fit project approach (i.e., Agile, Waterfall and/or a combination of the two methodologies) to succeed.
Lift Positive Risk-Taking
Most people hear “project risk” and they think of an adverse event or threat that may occur. Regardless, the term carries a negative connotation, but this common belief means you may be missing out on positive risks or opportunities that potentially have a beneficial effect on your project’s deliverables and goals. When you are presented with a risk (and most projects have inherent positive risks), don’t try to avoid it. Either accept it as is, try to increase the probability and impact of it occurring, or share it so other groups can get the full benefit. An environment that inspires risk and rewards success, but does not penalize failure is an organization to be reckoned with. The movers and shakers of tomorrow are taking risks today. In fact, here are some examples of positive or good risks. Reducing your Workload If a PM realizes that he or she probably needs fewer people for certain project tasks to be completed than originally planned, a door of opportunity is opened. The PM should take the risk or responsibility of reducing the team’s headcount to get more accuracy and credibility into the project’s plan (for example, total cost could be reduced and/or the completion date moved up). This process could also be used for tasks that have positive slack. The updated project plan would be re-baselined, but remember to keep the original baseline for historical reasons. Going under budget frees up resources for other projects and could contribute better forecasts in future projects. Growing your Business Let’s say you are rolling out a new e-commerce web site, but end up having too many visitors to handle the demand for your products and services. A specific example of this would be a web site that’s under heavy workload especially at year-end holiday sales. You took a risk and cut your capacity short and now you can’t handle the volume of customers, but this is really a “good problem” to have. Since you don’t want to skimp on customer satisfaction and want to continue to grow your business, you can now expand and acquire additional servers and/or increase your network data speeds. The bottom line is that it’s always great to own a company that has too much demand for its products than originally anticipated. You are well positioned to continually grow! Using New Technology Years ago, I was working on a new project to implement new Oracle databases for an in-house hard disk drive (HDD) system. Just before we started to execute the project, storage area network (SAN) drives became available. Management and the project team decided to take the risk and purchase them for our new Oracle system even though we had no experience with this new cutting-edge technology. As it turned out, the long-term benefits and savings for doing so were great! For example, the devices took up less than half the rack storage space versus what we would have used with HDD, time to access data was cut in half, the data transfer rate was doubled, and we improved our disaster recovery (DR) processes greatly. We ended up buying more SAN drives than we needed but we got big discounts based on the volume we purchased. And, overbuying turned out to be a positive financial risk because the surplus drives were eventually used for new expansion projects. Moving to The Cloud We all likely know of an organization that’s moved away from owning its’ traditional (or production) computer center and related infrastructure, and instead, has turned to third party internet-based data centers to achieve economies of scale. Benefits of “moving to the cloud” include getting applications up and running faster, dealing with less maintenance, and having the ability to pay as you use space. You can also increase your flexibility and scalability, and you’ll probably end up with a speedier return on your IT investment. Cloud computing is moving beyond its “immaturity” stage and overall, the shift is likely a positive risk for most organizations, but there are still some risks and/or pitfalls that you need to be aware of. Watch for the possibly of hackers getting into your systems, heavy data volumes that may cause brief outages or slowdowns, a system that isn’t as user friendly as you might like, or getting locked into a computing multiple-services contract you don’t want or need. Companies that are moving to the cloud should not initially “put all their eggs into one basket,” but should play it risk-safe by moving their non-critical applications to the cloud first. If this works out over time, then a move of critical applications to the cloud make sense—and eventually you’re able to phase out costly data center(s). Knowing Probable Outcomes For some types of projects (new PC rollouts or managing Oracle’s Enterprise Resource Planning upgrades), you will have “calculated” risks with a high probability of success. In short, you are learning from the past when you are looking to the future. Excellent sources for these types of projects can be found, specifically on PMI’s web site (PMI.org). Once logged in, highlight the Learning & Events tab, pick Publications (PM Network to access back issues). You can also find more PMI risk-related articles on their Knowledge Shelf. Educate yourself and learn from PMs who have assumed positive risk and seen successful results! The below figure is an example of a Decision Logic Table (DLT) that can be used for treating a specific project risk. A DLT is a documentation technique that can display an entire situation visually with all the alternatives shown side by side. Give it a try! If you do not use DLT, you may miss some solutions and could potentially sink your project. The DLT is made up of four major parts. The top left-hand corner contains the Condition Stub, a “yes” or “no” answer test to be made part of the solution to the problem. The top right-hand corner houses the Condition Entry which contains the “Y” (yes) or “N” (no) answers to the questions asked in the Condition Stub. The lower left-hand corner contains the Action Stub that itemizes all possible actions resulting from the conditions listed in the Condition Stub, and the lower right-hand corner contains the Action Entry which contains the appropriate actions based on the various combinations of answers to the conditions contained in the Condition Stub. The “X” will indicate “take this action” and a blank will indicate “take no action.” Remember to be positive and always look for opportunities! Summary Risk management in most organizations should start by being on the “alert” for positive risks and should learn how to embrace them so the probability of success rises. Positive risks could even be listed in the project charter with their associated benefits. Regardless, they should at least be documented as part of a project’s lessons learned so they can add value to future projects. The overall objective here is to boost the probability and power of positive opportunities! What do you think? What positive risks have you taken and what outcomes have you seen?
The 20-Percent Startup Solution
How to stop playing games with your project schedule Most baselined project plans are inaccurate because they have unrealistic start dates, finish dates, work hours, costs, and/or durations. The following are examples of this age old problem and how the 20% startup solution can be applied to build more accuracy and creditability into your project plans. Keep in mind that poor estimating during the planning phase is the largest contributor to project failures. Realistic Work Schedules The standard work week is normally set at 40 hours or 2,400 minutes. Let’s be realistic! No one is available 100% of their time to work on project(s)! People take breaks, have long lunches, have-one-one meetings, get stuck in traffic, have time off, and so on. Therefore, you should assume a resource is only available 80% of their time, at best, to work on projects. 80% of a work week is equivalent to a four day work week. It’s likely that management would never buy into four day work weeks, so you have to stick with the standard five days, but you should set the maximum units of availability for each resource at 80%. If a resource is available only half-time for a project, then set the maximum units of availability at 40%. Also remember, when setting up your project’s working time, to include corporate holidays, plant shutdowns, training, maternity leave, and/or individual vacations. Buffer Insurance Protection No plan ever runs according to schedule. It’s inevitable that 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 a “difficult” phase (for example, limited or no experience using a new technology) by manually extending its’ summary end date for that phase by 20% from its’ original duration. To be more clear, if the original phase duration is 100 days, manually extend it to 120 days. If you are fortunate and find out you didn’t need this entire buffer for a “difficult” phase, you can always reduce the buffers’ duration time to get an accurate project completion date. If you find out you defined a buffer task at the end of a “difficult” phase and didn’t need it at all, delete or inactivate it (inactivation removes values from your rolled up schedule). In this situation, I would recommend inactivating the task rather than deleting it, as you could later reactivate the buffer task if needed for some emergency reason. Managing Risks Wisely Most IT organizations talk a lot about their risk and issue management policies/processes which gives’ one an impression they spend about the same amount of time in each area. In reality, most spend most of their time on project issues. If companies spent more time on risk management (remember, the movers of tomorrow are taking risks today), they would end up spending less time on issues/change management which would ultimately mean they could go under budget and/or schedule for most of their projects. They might cancel some projects before they start because of the high risks involved. Since this usually is not the case, contingency funds totaling 20% of the total budget should be setup for each project. A risk is really an unknown event, but there are two types of risks. Known/unknowns are risks that are identified at the beginning of the project, and unknown/unknowns are risks that are identified during the execution of the project. A “contingency fund” of 10% of the budget should be setup for known/unknowns, and a “management reserve” of 10% of the budget should be setup for unknown/unknowns. Some of the monies from the “management reserve” could be used for minor changes to the project and other miscellaneous expenses. These two types of contingency funds or “safety margins” should eliminate padding task estimates (the worst habit to get into) and similar games. Instead, this approach will help to produce an honest project plan giving you more creditability and acceptance with stakeholders. Summary Running a project is akin to reading a book. You have a beginning (for example, a project charter) and an ending (for example, a close-out). The book consists of many chapters which gives you numerous “highs” and “lows” in running your project. If you follow the above tips, you will definitely have more “highs” in your project, which will improve your project’s performance and creditability. Furthermore, this will increase your chances of having a successful project that comes in on time and under budget! If you find out over time and through lessons learned that the 20% startup solution number is not accurate enough for some or all of the mentioned areas in your organization, then update the percentage number (for example, 15.5% or 25%). Lastly, continue to monitor the accuracy of all the percentages on an ongoing basis to see what works best for your organization. This is an update of PMI’s PM Network article from December 2015
Red Flags, Blue Lessons
Watch for these warning signs, so you don’t end up twisting in the wind! As a project manager (PM) for an international consulting firm, I was once assigned to a very large account that taught online classes through the internet. The company was called the High Intensity Teaching Corporation or HIT. This is the pseudonym used throughout, and for reasons that will soon be obvious, I found it managed to fly into some of the most dangerous red flags that warn of project trouble: a virtual office, an excess of PMs, overlapping projects, and risk aversion. Let’s examine these one by one. I’ll attempt to transform my agony into your benefit. 1. A Virtual Office Can Sometimes Be a Drawback In the past, I had set up shop Monday through Friday. This usually entailed flying to the client’s location early Monday morning and flying back home Friday afternoon or evening. However, as telecommuting opportunities advanced, I began to spend less time at on site with clients. I could show up Monday through Thursday, sometimes every other week. It all was dependent on the project’s progress, and my physical presence was my choice. This was great for me! I got more work done from my home office because I was spending less time traveling. Likewise, it seemed ideal for my company at first, but you know what they say about the transient nature of happiness?! Things quickly turn upside down! Red Flag: The first month I was assigned to HIT, I was “allowed” to travel to its headquarters on two consequent weeks. The plan was then for me to use my home as a “virtual office.” The bottom line was that HIT didn’t want to pay for my traveling expenses. It seemed reasonable enough, but this was truly a classic case of being penny-wise and dollar-foolish, and a show of how little regard they had for the value of PMs. As it turned out, my virtual office meant that my mirror image was physically at HIT’s headquarters as I had a phone, email, and getting plugged into their system was supposed to be a snap. I soon learned; however, that working for this account, my virtual office really meant working with handcuffs. In one situation, I advised that we should hold a one day workshop at HIT to brainstorm, review the many project requirements, and work on some initial solutions. The client thought this was an excellent idea because all vested parties were located at headquarters and we would accomplish more, but I soon learned I had to facilitate the workshop from my home using Skype. The time-zone difference caused headaches in this and other cases. I was two hours ahead of HIT, and I usually started work at 7 a.m. Since most HIT employees started between 8 and 9 a.m., I was really three to four work hours ahead, but had to take many evening conference calls, too. On numerous occasions, I wasn’t invited to key meetings, which made me feel out of the business’s mainstream. Of course, this made it difficult to manage priorities effectively. Blue Lesson: The virtual office makes you more flexible if you are working on multiple accounts as a PM, instead of a single one like I was assigned at HIT. In this case, I would have been more much more effective if I could have traveled to the client’s headquarters once every two to three weeks. If you are offered a remote PM role that doesn’t allow for much travel, take pause before you accept the assignment. Travel restrictions could be a red flag that signals not only the client’s reluctance to invest in you, but their view of your role as unimportant. If you must take the assignment, forewarn management about the extra hurdles you will encounter due to your stationary status. You may suggest that they use local people or contractors on the premises at no extra cost. 2. Too Many PMs Involved Can Cause Chaos I was originally brought in to work on one project, on a worldwide basis, replacing about 1,400 outdated servers with a lesser number of new powerful servers. This alone was a fulltime job; however, in today’s workplace, one fulltime job is often just the beginning. Red Flag: Periodically during my time with HIT, a new project would be thrown “over the fence” and hit me on the head. Figure 1 depicts how I felt. When I reviewed the histories of these “new” projects, I realized I was the second or third PM to take over each one, and all had been in existence for between 6 – 12 months. Furthermore, I realized some of these “projects” where really programs – usually a group of related projects working toward the completion of a single deliverable. I ended up with these unannounced projects because the group that owned them “reorganized” or felt they no longer fit in. I was very alarmed to see how many PMs (and client owners) had previously worked on them, and I quickly understood why these short-term endeavors were turning into long-term exercises. Working from my virtual office, it took me two to three weeks to get up to speed on these projects. Of course, this was all while working on my original fulltime assignment. Other red flags included the fact that no up-to-date project plans were in place, and there was too much dependency on a small number of key resources. Blue Lesson: Because it extends project length and cost, and disenchants the client, group reorganizations shouldn’t be used as an excuse for unloading projects. In my experience, if a project is thrown over the fence, so to speak, it should have a clean bill of health, updated project plan, and a good transition from the outgoing PM to new one. 3. Too Many Overlapping Projects Creates Unnecessary Work I went into my HIT role expecting most colleagues to understand the importance of an entire team or business unit having awareness of a project’s “big picture.” To me, this meant that the people involved or affected needed to know the project’s goals, objectives, master schedule, system architecture, and major milestones. When you are juggling too many overlapping projects, it’s tough (and vital) to keep track of all the details. It should come as no surprise at this point that HIT had many team members without knowledge of and consensus on the big picture, and much time was wasted defining details that ended up as throwaways anyway. Red Flag: Since I was working on a number of inherited projects, I realized that many projects lacked a big picture because they overlapped with one or more concurrent projects, mainly in the area of doing work on servers. HIT had over a hundred of active projects covering many different business areas, so it was extremely difficult to know if one project overlapped with others. For example, on one project, the application releases of a series of servers were being updated by one support group, and in another project, the Window’s operating system was being upgraded for the same servers by a different support group. These two project schedules weren’t coordinated, and efforts became duplicated, unknown dependent activities occurred, work tasks were done out of sequence, and payment confusions became the consequence. Blue Lesson: I advised HIT to find ways of eliminating unnecessary work and misunderstandings about who was doing what. In the case of the servers, if any new project involved servers, I realized that the server addresses should have been queried against the project administrative database to find possible matches to other projects. The PMs assigned to those projects should have been notified and work efforts coordinated. If the server addresses from the new project could have been validated against HIT’s server database to make sure the server’s description within the project matches what’s on the database, any information that didn’t match could have been corrected. 4. Risk Aversions Decrease Your Chances of Success On two of the additional projects I was assigned, HIT was always changing the scope and priorities at the last minute. These projects had been stumbling along for about a year and should have been finished by the end of 2017, but ended up being completed at the end of 2018. What does all this mean? Well, most people view risks in a negative manner, but risks can be positive in that they open the door for a better approach, creating new opportunities that may not have been available when the project began. Red Flag: The HIT projects were adrift because of constant changes, which hurt the team’s overall morale and effectiveness. HIT didn’t want to spend any extra money and instead expected my consulting company to take all the risk. In the short run, HIT would be saving money, but ended up spending more in long-run because of the necessity of providing additional support for outdated products that were no longer supported by their vendors. This kind of penny-wise and dollar-foolish thinking is a real impediment to progress. Furthermore, HIT lacked the discipline to meet its own schedule commitments, even though they expected me to meet mine. Blue Lesson: Management’s actions always speak louder than words. It is obvious that HIT and my company did not have a good working relationship. Senior management has to come together to overcome this type of adverse environment. The biggest factor that can make or break a project is the degree that leadership exercises effort at this. HIT had to learn that risk management is proactive management—and this includes the need to replace inadequate or outdated risk assessments. Risk management enables you to minimize future threats, seize opportunities, and achieve optimum results. All projects have risks, and if they go unacknowledged, the project is looking at failure. Numerous studies have shown that IT projects share some common sources of risk. One of these studies comes from the Standish Group, which shows a project’s success criteria and its’ relative importance. Using this criteria can help a PM look for areas of success by finding and reducing risks. Table 1 shows the scoring sheet. Notice the first three items account for 50% of relative importance for success. These are key areas to find and reduce risks. Summary As a PM, my time at HIT was fraught with frustration. Although at times these red flags left me twisting in the wind, I learned a lot from the blue lessons they produced—and I hope you did too!
Why Impartial Testing is a Non-Negotiable
Reducing the Risk of Project Shortcomings Project teams usually do their own (early) Partial Testing, which consists of unit and function testing. Unfortunately when the early phase is completed, the same project team may be tempted to go on and test their own projects’ component, system, and regression. This testing phase; however, should really be completed by a third set of independent eyes. See the table below for fuller descriptions of the described. The Galaxy Note Disaster A good example is that of South Korea’s Samsung Electronics rushing to market with the Galaxy Note 7 smartphone (see Figure 1.1) in August 2016. The device was tested in their own lab, unlike other cellphone manufacturers who use third party labs certified by the U.S. wireless group. As it turned out, many of the lithium batteries in Galaxy Note 7 phones overheated and burst into flames. Samsung ended up pulling the plug on this product two months in. Three million phones were recalled globally. This disaster greatly hurt the reputation/profitability of Samsung, as well as the economic development of South Korea (the company makes up about a fifth of South Korea’s annual exports). Eventually, Samsung hired outside investigators, who found that some batteries were irregularly sized or had other manufacturing flaws that caused overheating. Benefits of Impartial Testing The following are some of the many benefits of having impartial testing under separate control: Summary Partial testing should be completed by the development team before impartial testing starts, and these activities must be planned, anticipated, and have a trackable process. Impartial testing is all about reducing the risk of project shortcomings. It increases your chances for overall success and for having a satisfied client. With impartial testing, you’re also reducing operational life costs, which is a valuable investment to make! Partial and Impartial testing is about the total test plan, and defining the process and criteria for checking conformance to requirements (that of, the deliverable product or its components). Formal customer satisfaction surveys should always include a section on testing, and acceptance evaluation should never be left out the post project review. When Samsung rushed to the market with the Galaxy Note 7 smartphones, they were circumventing their own quality control process—acceptance decisions, re-work, and process adjustments. Ultimately, they paid a high price (about 5.5 billion dollars) for their non-conformance. Even more so, they hurt their reputation for quality. Note: the new generations of the Galaxy Note (versions 8-10 and their sister smartphones) have more battery space, thicker walls, and go through more intensive testing. In fact, Samsung now uses Underwriters Laboratories to certify new smartphone devices. People are likely to pay more for higher quality—or even the perception of higher quality. The lesson to be learned? Crisis management is much more expensive than risk management!
A Short History of Project Management
Have you ever wondered about the history of project management, or how it evolved into its’ present day usage? This article will cover most of the major project management happenings throughout history. The stages of time will cover the BC time period, the 1900’s where the root of modern project management was driven by the military, and we’ll end up looking at the ever evolving Agile methodology that more and more project manager are implementing now. Let’s go back to Egypt first Thousands of years before Christ, the Egyptians were building pyramids. Obviously, the architects and engineers were greatly involved in designing and building these huge complex structures. By default, these people were doing early project management by obtaining/transporting the heavy blocks of stones and related materials (procurement and quality management) and acquiring and scheduling the slave workers (resource and communications management) to do their work. Other early seeds of project management were developing (for example, building the ancient Greek temples and the Great Wall of China) around the world. Henry Gantt and his chart There were many men and women in the early 1900’s that made significant contributions for the application of analytical science to the workplace. One could say this was the birth period for modern project management. I would be remiss if I didn’t at least mention Henry Gantt. No discussion of project management would be complete without mentioning his contributions, as he applied the knowledge he learned during World War I building Navy ships by diagramming the processes with bars and milestones (see Figure 1.1). It goes without saying that this was very laborious to do by hand, but his famous Gantt chart is a standard format for displaying project activities and their corresponding start and finish dates in calendar form to this day. Project Managers (PMs) use Gantt charts as a standard tool for communicating project tasks and scheduling information, which is found in most project management software. Gantt’s contributions to military projects and to the overall project management profession have been enormous! The WWII Era During and after World War II, America’s Department of Defense (DoD) and its suppliers continued to focus on developing techniques and software to assist in managing large projects. The software included features such as generating a project network diagram to help create realistic schedules and the critical path to find the earliest completion date. Eventually DoD had their own project management methodology, which was product-oriented, and you had to use their methodology if you wanted to do business with them. The first three levels of their methodology uses work breakdown structures that cover project-end objectives, major product segments or subsections of the end objective, and decomposed components, subsystems, or subsets. These were the origins of the project as a unifying standard and management specialty. Eventually, project management was seriously looked at as a true profession. Another major project related happening was the growing popularity of value engineering (VE), which was widely used at General Electric. This functioned to help measure the value of alternatives (for example, using cheaper resources and/or materials to reduce project costs or design-to-cost) especially when there was a scarcity of resources. We saw this in action, when, during WWII, 1943 American pennies were made out of zinc-coated steel so that the military could use the copper for everything from shell casings to radio wire. These “steelies” were often confused with ten cent silver dimes because they looked so similar. Also from 1942 – 1945, nickel was in critical demand to help support the war effort, so it was removed from the nickel five-cent pieces, which were made up of a combinations of other metals. PMI on the scene The Project Management Institute (www.pmi.org) is an international non-profit society for PMs founded in 1969 and currently celebrating its 50th anniversary. PMI has almost 600,000 members worldwide in over 200 countries and many different kinds of certifications. The most popular certification is the Project Management Professional (PMP), which has become the de facto standard certification for PMs. There are almost one million active holders of this certification. The next most popular certification is the Certified Associate in Project Management (CAPM) with almost 40,000 active holders. If an individual is serious about project management, they should seek the PMP or a CAPM certification. The PMP certification requires more work experience then a CAPM, but both are respected professional credentials and add professional marketability to the owner. Currently, I am beginning to see a long-time overdue new trend in job postings for different types of engineers that prefer applicants to have a PMP certification. In fact, many universities that offer engineering programs (undergraduate and graduate) are beginning to make it a requirement that their students take some project management courses. This recent phenome is happening in other degree programs also (for example, Master of Science in Supply Chain and Logistics Technology at the University of Houston). If I was a young engineer graduate, I would make it one of my top professional goals to eventually acquire one of these PMI certifications, making myself more marketable and helping me to rise to the top. Certification is the icing on the cake that offers evidence of the mastery of generally accepted project domain knowledge and demonstrates commitment to professionalism. Also, PMI has many different publications, seminars/webinars, and a valuable Knowledge Shelf library which has a wide-range of articles on many different topics submitted by its’ members. Software Development Approaches There are now many types of software development approaches or models to choose from. I suggest an organization should strive to have as few models as possible. Why? So that the project members will be most effective and productive using a model they understand and have experienced. Additionally, any model that is used should be examined routinely for improvement. I want to zero in on the two most popular used models. They are Waterfall and Agile. The Waterfall model has been the traditional approach used since the 1970’s. The name comes from the appearance of the model. That is, when one stage is completed, the next one is started so there is a downward flow. The stages are usually requirements, design, development, testing, and deployment. This model is well suited for medium to large size projects that have well defined requirements. Unfortunately, the project success and failure rate following this model was not very good. The Waterfall model tended to limit interactions and dedicated team work, and put an emphasis on burdensome steps, procedures, and tools that often caused “scope bloat” or unnecessary features in a project. From many studies (for example, the Standish Group, a software statistical company) about 30% of projects were cancelled before they were finished, about 60% of projects were challenged because they had many different types of gaps, and 10% were considered successful. These percentages greatly improved (about 40% of projects were considered successful) by moving to the Agile model. I first learned about the Agile model around 2003. Admittedly, I thought it was a fad that would never catch on with management (or change agents). Boy, I was wrong! In the past decade, Agile has become mainstream in most organizations. According to a recent survey from PMI, 80% of companies use Agile at least some of the time, and 40% said they use it either often or always. Most of the organizations that are using Agile are at a “still maturing” level regarding Agile practices. Agile approaches are a response to the need to modernize project management for small scale projects where clients have difficulty defining requirements. The bottom line is that it revs up your software development (for example, proto-typing) with a faster delivery time and a more flexible approach, which leads to higher user satisfaction. Agile is a great software development approach for software houses like Microsoft, Oracle, SAP, and web-design organizations. The core values of Agile are: Even though the roots of Agile methodology come from software development, the approach can be used in other areas of development like manufacturing processing. Today, most companies use the Waterfall and Agile models. In fact, many projects may use a hybrid of both models depending on the type of project being worked on. For example, embedded systems where the hardware, firmware, and software are used for large enterprises. When the latest PMBOK Guide was published in 2017, PMI also published the Agile Practice Guide in partnership with the Agile Alliance (www.agilealliance.org). I have found this to be an excellent reference book to have and learn from. The Agile Alliance site has extensive resources to help you, as well as an index of independent Agile community groups across the world. Finally, the newest and fastest growing accreditation (almost 30,000 holders) from PMI is the PMI Agile Certified Practitioner (PMI-ACP). Summary Throughout the rest of this century, I will be excited to watch the advances in project management and the methodologies used. Organizations, to survive, will have to continually redefine themselves at a faster and faster pace to keep up with their competition. How about you? What changes to project management are you looking forward to?