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.

Power, Politics, and Providing for a Project: Part 2

Power, Politics, and Providing for a Project: Part 2

Trust Building between Stakeholders and the Project Team Is a Powerful Asset In Part One of my article on power, politics, and providing for a project, we looked at two areas of importance: the project’s charter and the communications plan. I’d like to continue the conversation by outlining specific suggestions for building trust between stakeholders and project team members.   Eight Tips for Building Trust Interactive communication is still the best form of communication. Be present and available to your stakeholders and team. Be a good listener by concentrating on what is being told you. Effective listening includes asking questions to clarify what is being said or asking for examples. If still in doubt, paraphrase what the speaker said to be sure that you understand what he/she meant. Using non-verbal listening techniques like making eye contact, being expressive and alert, and using body language to show emotion and agreement will increase the value of a two-way conversation. Tap into the potential of the stakeholders (and others) because they usually have value to add to the project. Practicing this is a win-win combination for you and leaves them feeling pretty good, too. For example, ask for assistance in reviewing a test plan, a memo, or an idea. When you are wrong, admit it! This can change the mood from one of confrontation to collaboration. Remember, being stubborn only builds walls (not bridges) between people. If you have bad news to deliver, don’t put it off. When you do break the news, be sensitive to your listeners and have an action plan in hand to deal with any major issues. In short, the PM needs to be an honest broker of information to be able to salvage the worst of projects. Treat others as you would like to be treated. It shows respect for the individual. Don’t be blinded by the ease of these words – there is precious treasure (or Golden Rule) here! Saying “thank you” can go a long way in gratifying people and getting their support. It’s a short, but very potent statement! Be strategic when you go to coffee or lunch. Invite a stakeholder or team member. You’ll get to know each other in an informal setting and generate a better working relationship. Communications management includes your plans for handling your project’s change requests, risks, and quality. Always remember that quality is providing a product that satisfies the customer and covers a broad area such as function, cost, minimal defects, being dependable, good level of service, being competitive and so on.   Final Thoughts on Navigating Project Politics This topic has covered the importance of effective communications (especially listening) in a project. PMI states that up to 90% of a PM’s time should be spent on internal and external communications, so failure to effectively accomplish this goal will definitely have adverse effects on project performance. Many surveys have shown that ineffective communications is the number one cause of project failures. Obviously, effective communications is required between the PM, sponsor, stakeholders, and project team to help increase your chances of being successful. Another aspect of effective communications is conflict management. The important thing to remember is that conflicts can’t be left to fester and increase. A PM must be on the outlook for issues and activate a strategy to deal with them. Bring patience and respect, use a problem solving approach, and construct an agreement that works to the satisfaction of the stakeholders and other team members without creating new conflicts. As we all know change is a constant happening all the time in an evolving project. The charter is usually like the tip of an iceberg, with the other 90 percent of the project lurking underwater and unfolding over time (e.g., new people will emerge who may affect the project’s goals/approaches and chances for success). Always remember that we are all in this together – coming together is a beginning, keeping together is progress, and working together is success.  

Power, Politics, and Providing for a Project: Part 1

Power, Politics, and Providing for a Project: Part 1

Trust Building between Stakeholders and the Project Team Is a Powerful Asset The following statement made by Dr. Gary L. Richardson, University of Houston, is one of the most commanding I ever heard related to project management and one that all project managers (PMs) should be aware of: “Projects are natural breeding grounds for conflict resulting in ineffective human behavior, which must be dealt with effectively for the overall success and health of a project.” Every organization has unique power struggles due to changing constraints to project resources, environments, goals, and/or deliverables. Competition for resources makes conflict a dominant issue, and PMs must pay attention to company politics to be effective. Usually, the most difficult limitation for a PM is getting the right team “loaned” to them from different functional or line managers (e.g., database, security, and/or infrastructure). Keep in mind that the selected members owe their first loyalty to their functional manager, and that they might be assigned to multiple projects, which eventually might cause problems in meeting individual project milestones. Furthermore, outsourcing can come into play, often motivated by a desire to cut costs, but causing potential gaps in operating performance. I have seen many PMs assigned a full time project that runs close to a year or beyond that should have their own office and/or team work room to be more productive. More often than not, though, this isn’t allowed them, and the lack of required work space results in difficulty. Remember, organizations need to be supportive to their PMs in order to have successful projects. Trust building between stakeholders (those with a vested interest in the outcome of a project) and a project’s team fosters loyalty and results in a positive working environment that increases the chances of success. In most companies there’s room for improvement—wouldn’t you agree? Two areas, in particular, are important to look at: a project’s charter and the communications plan. We’ll cover both below.   The Project Charter A new project requires planning, skilled leadership, and a little luck. Since every organization is unique, the approach or model for a formal Charter varies, but always should build a business case outlining the value of the project and procuring sign off by management. The Charter serves as a high-vision target that is used to produce a business case and hopefully leads management to further approve a more detailed definition (e.g., scope document). In other words, a Charter is like a formal press release (usually 1 – 3 pages) to the organization that a specific project is being authorized for further study of its value. At the end of the charter process, management will either decide to reject, put-on-hold, approve with modifications, or approve the development and implementation of the project. At a bare minimum, a Charter (see Figure 1.1) will include the name of the PM, project sponsor, tentative budget, and the project objectives. A project sponsor is a person who normally has a large degree of influence in the organization, typically is responsible for the budget, usually reaps the benefits of the project, and champions the project through its approval phases. Some organizations go way beyond the basic template shown in Figure 1.1 and might produce a longer charter that goes into the number of team resources needed, their names, key deliverables, realistic cost estimates, risk summary, success criteria, and what the of PM’s authority is. More detail is always better in making a “go or no go” decision, but it takes more time to do this. A long charter could end up being the foundation for a scope statement, which defines a project’s boundaries such as what is included (e.g., deliverables) and what is not included (e.g., elimination of mistakes and sometimes dangerous assumptions).     A Communication Plan Project status tracking and reporting processes should be defined at the start of any project as part of the communications plan, which describes the information needs of the stakeholders, project sponsor, and the project team. This overall communications plan should cover who needs to know what, when they need to know it (e.g., weekly, bi-monthly, or monthly), and how the information should be received (e.g., paper, email, or a collaboration website). It’s important that the PM ask each stakeholder to pinpoint their preferred form and frequency of desired communication. Their needs usually depends on how active the stakeholder is in the project (e.g., an occasional contributor or someone that is providing financial/political support). There are many ways of reporting a weekly, bi-monthly, or monthly status of a project. As much as possible, Microsoft’s Project, Excel, Visio, and/or PowerPoint graphics should be used to depict the status of a project which is easier for non-technical people to visualize and understand. Depending on the size and length of a project, PMs need to have status meetings at least two to four times a month with their stakeholders to cover the progress made and mitigate risks  before they become issues which could hinder the development of team relationships. Meeting less frequently allows problems to fester unchecked and could thereby do great harm to the overall project (Whitten 1995).   The Useful Stakeholder Directory It’s also smart in the beginning of a new project for the PM to generate a Stakeholder Directory (see Table 1.1), which allows you to make sure you identify the right people to focus on. This is a living document that will like be in need of constant updating. If in doubt about a stakeholder, include the person, and if you find out later they aren’t interested, delete the name. It’s better to be safe than sorry. The table template below could be expanded to put in other useful fields. For example, you need to know if the stakeholder is a driver, supporter, or an observer. A driver is someone that defines the results, a supporter is someone that helps you, and an observer is someone that is interested in your activities and results.     Keep in mind there might be some stakeholders who view the project negatively (e.g., a new system might reduce their head count or they have a personal agenda that is not being addressed for the good of the whole). Pay attention to these issues, left unaddressed could hurt the project’s outcome. If there are a lot of politics at play, it’s important that the PM and the sponsor recognize this and do their very best to work along with dissenting people. In Part Two of this article, I’ll be bringing some suggestions for building trust between stakeholders and project team members.  

Reshaping Project Managers for the Future: Part 2

Reshaping Project Managers for the Future: Part 2

Upcoming Movements in Project Management and How You Can Prepare   We started to discuss in Part 1 of this article what project management opportunities are ahead and how PMs can be getting ready for them. I pointed out that the majority of small to medium businesses (SMB) are 10 – 20 years behind the times when it comes to technology and that these companies would benefit from bringing in a project process consultant (PPC).   Diagnostic Affiliates of Northeast (DAN) Let’s consider Diagnostic Affiliates of Northeast (DAN) as an example. Because of the their ailing legacy infrastructure and support systems, what pained DAN the most was the lack of in-house expertise and a growing sense of not knowing what to do as their business grew in depth and breadth. After researching a number of vendors that specialize in health systems, DAN decided to go with the popular Patient Intake Applications Suite (PIAS) from Phreesia which uses a Software as a Service (SaaS) model. This on-demand software is typically assessed by users using a thin client (a lightweight computer built to connect to a server farm from a remote location) and web browser. The choice is a common one for office systems, accounting, and customer relationship management. Phreesia (www.phreesia.com) is a healthcare software company founded in 2005 with a background of software analytics and engineering. Their future growth potential looks great! Phreesia brought in a Project Process Consultant (PPC) to study DAN’s current systems. The consultant worked with the client to decide what processes they wanted to keep, what could be configured within the modular PIAS, and what new processes would replace the legacy processes. Some of the immediate benefits of the new installed system are: Phreesia had a number of different thin client check-in devices to choose from, and DAN decided to use only the PhreeisaPad shown in mustard in Figure 1.4. This consumer-friendly tablet includes a credit card reader and allows patients to update their information, sign consent forms, and pay copays securely from their seat within the waiting room. Going a step beyond, current patients don’t have to touch the PhreeisaPad if they want to avoid picking up germs from previous patient handlers. They can go online from their own device to set up an appointment and update any information that has changed. Once logged in, users have access to additional information like left messages, medications, results, appointments, health records, etc. Simplifying arrival by decreasing paper clipboard waiting time has the benefit of freeing up administrative staff for higher valued tasks. It also leads to patients having more productive time with the medical staff. PIAS’s includes a suite of reports called “Analytics” which helps DAN to understand their intake processes and monitor performance like patient payments and operational health.   Consider the value of the PPC in this case, and how he/she could be paired up with the Strategy Project Manager (more on that below) by selecting a process to pick the right projects so the organization can be successful.   Business Analytics Business analytics (BA) depends on getting large amounts of high quality data across different systems (e.g., Oracle, IBM, and/or Azure databases) and deciding what subsets of data adds reporting value to the organization. This value can be used to learn “insights” from past performance, so you can do better business planning and be more competitive. Henry Ford used BA to help plan and build his assembly lines, and many companies use it today for customer loyalty programs. Another example is Microsoft’s Power BI (Business Intelligence) Desktop and their similar ecosystems (e.g., Power BI Pro), which is really a BA service where end users can create enterprise reports, live dashboards, and rich visualizations themselves versus depending on their IT department. Unless they are trained, most end users won’t have the expertise to work across different systems and will need an experienced Business Analysis Consultant (BAC) to help them accumulate the information (i.e., actionable intelligence) they need to share and run their business more effectively. This is an area all PM’s should consider in future career planning.   Strategy, Strategy, Strategy Strategic Project Managers (SPMs) and Chief Project Officers (CPOs) will soon be breaking the doors down to get into the C-suite of any organization that is driven by information and technology. This person will have to know the business, be an experienced PM, be part of the portfolio decision making process, and be an effective innovator and communicator. Obviously this person has to be a skilled leader (e.g., PMO director, CIO, or COO), highly respected, and have good relationships with stakeholders! Equally important, this person would be an influential collaborator in defining and helping to deliver the organization’s strategy.   The SPM or CPO serves as a crucial interface between the C-suite and the organization in translating strategy and goals into projects. He/she understands the processes and advantages that need to take place for the project to be successful. Furthermore, this person can help the organization pick the right projects.   End-to-End Project Managers The previous job topics discussed in this article show where projects may transition from the PM to the business owner. End-to-end PMs go to the next level by taking ownership of a new product or service. In fact, the PM becomes responsible for providing the benefits. This is actually happening in China and slowly being embraced by Western countries. A good example of this is a Chinese company, The Alibaba Group (NYSE symbol: BABA), which is one of the world’s largest e-commerce, retail, internet, AI, and technology companies. They are fast to market being an Agile-project-based organization and quickly converting ideas into products and services. It’s a much more innovative and complete way to view PMs and project management, in general. Keep in mind these End-to-end PMs need to have good communication/salesmanship skills and be able to think strategically because they may be taking on more future projects than fit into their work domain. These types of fast-to-market organizations are looking for leaders that have less technical expertise and more end-to-end expertise with strong facilitation skills. These PMs usually develop a stronger business understanding with commercial insights, which should open the door for them moving up to the executive levels of their organizations. This type of environment could become the future direction of project management, and to get there, PMs need to get out of their comfort zones, adapt, and start playing more leadership oriented roles. It should be noted, however, that in order to go in this direction, organizations need to become more flexible overcoming silos and traditional organizational structures so the work done is project-based!   Summary In the last 30 – 40 years, the growth of technology has been mind boggling! Unfortunately during this period of rapid growth, processes were left far behind. For example, many software developers are still using the methodologies (e.g., Waterfall) from post WWII (these approaches were derived from heavy manufacturers using large mainframes and don’t match up with today’s technology). Traditional projects suffer from one major problem—scope bloat or having too many features that add little or no value to a newly implemented system. Consider Microsoft Word. It may have about two hundred features in it, but how many are you actually using on a regular basis? Maybe a dozen? When a new version of Microsoft Word comes out, it will have many new features that you probably won’t be interested in or use. So, there will be no immediate rush to upgrade. The point is that technology is advancing so rapidly that it’s beginning to outpace the public’s capacity to fully understand it ramifications. This means that sometimes inventing the future can cause internal problems for some large technology companies. These companies may have to reboot their own culture and/or use project process consultants to update their delivery systems and expand product lines to have a bigger retail footprint. Project managers need to change with the times to become champions of these changes, and while they are at it, modernize project management. A focus on the areas we’ve discussed in this two part article, can help PMs future-proof themselves and differentiate from others that have a similar IQ’s and education. Overall, look at your soft skills, increase your professional networking, have a positive attitude, and be resilient. All the “reshaping” PMs need to have is the ability to help able set a strategic direction for their organization, constantly improve their communications, and learn sales skills to help build up your toolkit. As mentioned in the above, companies are beginning to realize they want to hire people that have knowledge of their business areas, as well as project management skills. This future is bright and right around the corner. Start getting ready now!  

Reshaping Project Managers for the Future: Part 1

Reshaping Project Managers for the Future: Part 1

Upcoming Movements in Project Management and How You Can Prepare Have you found yourself wondering what project management opportunities are ahead and how you could be getting ready? We know most white collar jobs as they exist today are going to be radically reconfigured in the near future. Forecasting your upcoming career and getting ready for these changes will be key. Computerworld’s 2014 annual forecast survey showed that IT budgets are expected to increase with the top five priorities for spending being on the following: Security technologies Cloud computing Business analytics Application development Wireless/mobile As you can see from this list, it’s becoming more essential that every IT worker have some project management and digital-age skills, so they can thoroughly understand the underlying technology they are responsible for building. The reverse will also be true —PMs will need to have strong IT knowledge and awareness of future technologies. Reshaping roles and skills in this digital-age is needed for PMs to thrive. We know this because these technologies will continue to evolve at a faster and faster pace. I see several stages of movement that will affect the direction and roles PMs should be following. Let’s look at each individually.   Agile Project Management Agile had its early origins in the mid 1990’s. True be told, initially it had very little acceptance in the IT world, but, in the past decade, the acceptance of Agile in organizations has taken off exponentially. I’d like to think this has been because of the benefits of more user transparency, the ability for frequent inspections, and the flexible adaptation capabilities! With shorter lead times and faster software development productivity (along with greater flexibility/stability), PMs need to become familiar with Agile. You don’t have to be a PM to become an Agile Scrum Master (servant-leader or project facilitator), but if you are a PM with Agile experience it’s a real plus. For an Agile project to be successful, you need a team that really works well together.   Cloud computing and services are central to digital transformation. Challenges exist because existing business processes and traditional project management itself has posed a risk to successful adoption of the cloud, which many companies are moving to. Cloud projects are those that can be done in an eye blink and are not usually suited to waterfall or phased projects. Using the Agile methodology improves an organizations ability to roll out new cloud solutions and meet business needs. This rapid rollout reduces costs and increases flexibility because resources are freed up to address core business priorities and/or other projects. The whole methodology fosters a culture of innovative technological solutions and delivers better business benefits to internal and external customers. Furthermore, as a PM, you should consider the certification offered by PMI to become an Agile Certified Practitioner (PMI-ACP). Since more and more companies are starting to use Agile for projects, you would be more useful and valuable if you added this certification to your background. Agile principles and the Internet of Things (next topic) are made for each other. The pairing of these two concepts for product development projects helps to reduce the delivery life cycle time and promote the continuous and rapid flow of value.   Internet of Things (IoT) The management consulting company, Mckinsey defines the Internet of Things (IoT) as follows: In what’s called IoT, sensors and actuators embedded in physical objects – from roadways to pacemakers – are linked through wired and wireless networks, often using the same Internet Protocol (IP) that connects the Internet. The sensors enable the monitoring of devices everywhere and collect a myriad of data that can be analyzed. The data is then used to understand complexities of the world, and as a result improve efficiency in all areas of life – at home and work. Examples of these “smart cities” are connected cars, smart homes, wearables (e.g., Apple watches), and different ways of measuring and analyzing big cloud data by streaming data from sensors or data-in-motion. The heart of IoT resides in the source of the data, which are the sensors. These smart devices generate data activities, happenings, and influencing dynamics that provide visibility into performance and support decision processes used by a variety of major industries (i.e., manufacturing, electric utilities, transportation, automobiles, and many retailers). OK, let’s not forget Amazon, which optimizes its operations with IoT. In short, having machines connected means you are informed to make better and faster decisions.   A good example of an IoT application is SMARTank’s monitors that are designed for liquid level measurement in stationary tanks that can contain diesel, lube, home heat, propane, or gasoline. The architecture is completely wireless and the monitors “call-in” via cell phone signal several times a day. This helps with inventory planning (you know exactly when your tank levels are low and need to be replenished). The customer benefits from this by strengthening their business and mission outcomes, and it drives operational effectiveness. PMs of the future will play a major role in the implementation of IoT.  Knowing the importance of accurate data and measurement, successful PMs should really become the first backers for IoT. PMs should have the skills to integrate IoT into existing systems and in setting up its handling big data. It’s important that organizations and PMs are willing to adopt new methods for using IoT to explore new business opportunities.   IoT is in its early stages, but is already seen as a powerful idea—one that’s considered much bigger than its hype. IoT and other technologies (e.g., artificial intelligence or AI) are helping companies transform processes and business models, empower workforce efficiency and innovation, and personalize the customer/employee experience. All of us that use the internet are interacting with AI. For example, Amazon uses AI to guess what else we might want to buy. Don’t underestimate how much this is stimulating millions of impulse buys. According to the Boston Consulting Group (BCG), spending on IoT applications is predicted to generate $64 billion dollars by 2020 and Gartner, Inc. predicts that the IoT will be made up of 26 billion smart “units” by then. Furthermore, manufacturing, transportation and logistics, and utilities are expected to account for 50% of IoT spending by 2020. There is no question that IoT is becoming a critical part of business strategies going forward! PMs need to consider this and reshape any traditional approaches they are still hanging on to to be relevant in a changing ecosystem. A comparison between the traditional approach to project management and IoT related project management is summarized in Table 1.1 and is based on seven common factors – planning, complexity, scope, collaboration, project approach, documentation, and customer focus.     Large companies like General Electric, Microsoft, IBM, and Cisco are all making major IoT contributions. According to Crunchbase, a database of start-up companies, there are almost 4,000 active IoT companies around the world. Herein lies much opportunity for PMs. For example, telecom PMs with expertise in cellular/wireless networks, utilities PMs with expertise in improving reliability, and performance PMs that have experience in using IoT sensors and data resources to identify waste delays in your logistics process will all become more and more invaluable.   A Focus on Project Processes The majority of small to medium businesses (SMB) are 10 – 20 years behind the times when it comes to technology. With their outdated business systems, these companies would benefit from bringing in a project process consultant (PPC).     In Part 2 we pick back up with a case study illustrating the importance of a PPC. Please tell us in the comments what you are doing to prepare for the future of Project Management.  

Project Portfolio Selection Using NPV (Part 2)

Project Portfolio Selection Using NPV (Part 2)

Turning the whole system into something greater than the sum of its parts   In the first part of my article, we covered how the selection of projects is crucial to Project Portfolio Management (PPM), and we saw firsthand, by looking at a few case specific scenarios, how true this is. But, what about the financial formulas available in MS Excel and Project? Let’s consider how they play into this analysis.   Microsoft Excel and Project Excel has many great financial formulas (i.e., =XNPV(rate,values,dates)) that are easy to use and should be used as tools for project portfolio selection. Two formulas that are related, but just “estimates” are XNPV and XIRR (or Internal Rate of Return). You must be careful when you use them, so you are not misled. As I said, they are just estimates. The main difference between the two is that XNPV calculates the value of the business today, and XIRR calculates how fast the business or rate appreciates in value (i.e. its rate of return).   Microsoft Project interfaces with Excel (and Visio) offering many different kinds of visual reports showing financial information in bar graphs, pie charts, and/or line graphs. These can be very useful in project status meetings. To generate these reports in Project, go to the Report tab’s Export section and then click Visual Reports. The financial Excel reports include: baseline cost, cash flow, earned value over time, and resource cost summary. Furthermore, these reports can be customized as needed and saved as Excel files.   There are three main NPV categories (Revenue, Operating, and Competitive Necessities) that you will find below in selecting what projects to work on, and these should be listed in Project’s first line (WBS = 1) under Notes. To do this, right click the first line, select Information and the Notes tab, and copy/paste the selected project’s NPV Excel data in it. I recommend doing this for historical reasons (i.e. why this individual project was selected) so that you’ll be able to provide evidence in legal proceedings, if needed. Additionally, you can later test your cost/NPV selection process to see if it’s correct or needs tweaking. See Table 1.7 below for an example.   Table 1.7: Why Project 2 was Selected   NPV Categories Revenue Necessity: This refers to selecting projects (from Table 1.6) that have the highest Profitability Index. Most companies want to decrease costs and increase revenues as much as they can.   Operating Necessity: Sometimes an organization has to go against its formal project decision-making process because of external or internal factors. For example, Tables 1.4, 1.5, and 1.6 have the same ten projects that were prioritized and showed the best projects based on their own selection criteria. Let’s say project 10, which was not selected in Tables 1.5 and 1.6, is a new mandated U.S. federal law like the Sarbanes-Oxley Act or the Dodd-Frank Act (both related to corporate compliance on financial regulations). Of course, because of the nature of the project, this one needs to be incorporated into your operations.   This means that you would use your selection criteria on the first nine projects. In a different scenario, let’s say Project 10 has been approved (another free-pass) by your board of directors and/or CEO to improve the company’s public image, which may be at a very low point. In this case, again this project would have to be implemented, which means you would use your selection criteria on the first nine projects. Other “free-pass” projects may include advoiding litigation, addressing regulatory issues, and reducing exposure.   Competitive Necessity: These projects are similar to Operating Necessity projects, but are less critical. Competitive Necessity projects are usually in response to a competitor’s actions or a change in technology or markets that could lead to a new strategy for the organization. For example, computer hard drive manufacturers had to upgrade their manufacturing facilities to change from making hard disk drives (HDD) to making storage area network (SAN) drives. The long-term benefits and savings for their customers were great! The devices took up less than half the rack storage space versus using HDD, time to access data was cut in half, and the data transfer rate doubled. Likewise, if project 10 from Tables 1.5 and 1.6 is an approved competitive one, then you would use your selection criteria on the first nine projects.   Other Financial Decision Considerations Payback Period: 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. Then, the payback 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% as follows: the $100,000 returns is divided by the $500,000 investment, which equals a 20% rate of 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. NPV does take into account the time value of money (i.e. the net cash flows at different points in time), which gives a more accurate picture of financial performance.   Depreciation and Income Tax: Organizations may need to acquire capital assets that are depreciable for income tax purposes over a period of accounting periods. Assume a new host computer costs $500,000 with a life expectancy of five years with no trade-in or resale value at the end of five years. The annual tax deduction for depreciation would be $100,000 ($500,000/5) for five years. If there is a trade-in or resale value at the end of five years of $100,000, then the annual tax deduction for depreciation would be $80,000 (($500,000 – $100,000)/5). The possible tax effect of depreciation must be considered when making investments especially when depreciation deductions will reduce annual cash out-flows by paying less income tax.   Reducing Risks: One of the main keys to PPM is to diversify investments in such a way as to reduce the overall risks within a portfolio. While it’s important to optimize the total financial value of projects within a portfolio, you still want to minimize the risk exposure by having early and frequent risk reviews for each project. Also, it’s important to be aware of your external risks (i.e. customers, suppliers, competitors, industry, and economy) and internal risks (i.e. resource estimations, schedule estimations, scope definitions, and scope creep). As one can see, reducing risks is part of portfolio balancing and optimization that should be done on a regular basis. It’s important to always remember some things will go wrong in pending and approved projects within an organization. Of course, it’s easier and faster to expect such issues and have a plan for how to respond.   Summary Many companies still use unscientific approaches when it comes to PPM evaluation and selection. These approaches usually lead to wasted monies, resources, and unfavorable politics. Having formal methods for portfolio evaluation and selection, such as those described in this article, will go a long way for your organization and help to eliminate much of the political flavor in project selection. PPM should improve your project selection process, give you a better understanding of project value, and could help you obtain funds for a project. As much as possible, you should always want to pick projects and programs that meet your organization’s strategic goals. Be aware that many companies’ strategic plans are more like mission or vision statement than a road map, and very few companies do “post audits” that could confirm whether investments actually paid off. Even if a post audit showed negative financial outcomes, it might expose a manager’s data gathering errors and manipulation efforts.   It’s important that portfolio managers have solid financial and analytical skills and understand how projects and programs can increase NPV (or other selected financial formulas) while supporting strategic goals. Furthermore, portfolio managers might consider getting certification through PMI as a Portfolio Management Professional (PfMP) to increase their skill level and/or future opportunities. There are only about 400 holders of this certification, and in my opinion, there should be more. Another PMI certification to consider, one of which there are about 2,000 holders, is the Program Management Professional (PgMP) certification.   Since the PPM approach is not a “one-size fits all” solution, your organization should research other optimization methods and models for PPM evaluation and selection to find their best value equation. This could include integer linear programming that will maximize or minimize some target area, what-if-modeling, and/or software that shows inter-project dependencies to understand what is going on in other projects. All of these considerations will lead to better resource allocation. Most of these features can be found in project-portfolio software products like Microsoft Project Portfolio Management (microsoft.com) or Primavera Enterprise Project Portfolio Management (oracle.com). Some of the functionalities include staffing projects from a common resource pool and tracking activities on multiple projects to show inter-project activity dependencies. More importantly, these tools can assist in the selection of the right mix of strategic projects. Another advantage to having this kind of software is having common project communications (i.e. tracking reports and accomplishment reports). This common language fosters team collaboration throughout the organization by promoting well established project-management and data-oriented policies, processes, and procedures.   The people running PPM need to learn to communicate better to build trust and to insure their messages are clear and understandable within their organization. Communication management should always include rich visual dashboards that have hyperlinks to allow people to drill down on their own time to see more detailed information. These dashboards (i.e. pie charts, Gantt charts, and status indicators) will help a PPM to deliver status information in a precise and timely manner.          

Project Portfolio Selection Using NPV (Part 1)

Project Portfolio Selection Using NPV (Part 1)

Turning the whole system into something greater than the sum of its parts   A crucial part of Project Portfolio Management (PPM) is the selection of projects. This is an ongoing dynamic process. In the following two part article, I will be demonstrating Net Present Value or NPV. PPM is simply managing your company’s resources. It has less to do with project management skills and more to do with strategic planning. In selecting projects, you want to pick the ones that create the greatest return and contribution to the strategic interests of your organization within the confines of your annual budget. Going a step beyond, you really want to optimize the portfolio and turn the whole system into something greater than the sum of its parts. Think of it this way – if each project is an instrument in your company’s orchestra, then you have programs made up of wind, percussion, and string instruments. You want someone – the conductor – to enhance the whole system by having the technical skills, leadership skills, and respectability to lead the orchestra in creating beautiful music. See Table 1.1. In many ways, PMs and musical conductors have common denominators. For example:   They have the capacity and desire to lead/guide their project teams or musical ensembles. This includes cooperation and networking.   They have to be good communicators. Besides verbal communication with their orchestras, conductors also communicate through hand gestures, typically with the aid of a baton, which means they need to be in good physical shape! So should PMs for that matter.   They are involved in bringing talent together and scheduling activities.   They have to interpret the overall project plan or musical scores.   They have a rehearsal process. That is, to review work-in-process plans or practice musical scores. Practice makes perfect!   They have to satisfy their customers. Whether users/stakeholders or audiences, hopefully the customers are happy people!     Projects, Programs, and Portfolio Differences Throughout my career working with many users and executives, I have learned there is a lot of talk about projects and portfolios, but not much reference to programs. Many times I have been assigned a “project,” analyzed the endeavor, and realized that in actuality it was a group of three to five related projects. When I gave status updates, I always used the term “program,” although quite frequently the users and/or executives would call my endeavor a “project.” It always bothered me. What I got from this was that they really didn’t know the difference between a project and a program, or they did, they just didn’t care about the semantics (the whole “just get the darn job done!” mentality). Before I get into project portfolio selection, it’s important that we cover the differences between projects, programs, and portfolios.   Portfolio managers (PfM) balance conflicting demands between programs and projects and manage them to achieve the anticipated benefits. Program management (PgM) focuses on achieving the cost, schedule, and performance objectives of the projects within the program or portfolio, while project management (PM) is largely concerned with achieving specific deliverables that support specific organizational objectives. The Standard for Portfolio Management – Third Edition (Project Management Institute, 2013c) documents the attributes, differences, and coincidences among the three (3) types of practices as follows (Table 1.2):     Prioritized Project Portfolio Everyone would like to have a prioritized project portfolio that holds maximum value over a specific time period, but there are many variables (i.e. having enough money and sufficient resources with the right skills) to be considered. The key goals of the portfolio optimization process are to align project work with the strategic direction of the organization, maximize the value of the portfolio, and to balance the project portfolio. The following NPV financial case studies will hopefully provide us with the insight we need to improve a portfolio from a solid one to a much more profitable one. NPV is one of the most widely used financial attributes because it measures the financial return of an investment, which uses external factors like inflation, investment risk, and cost of borrowing money.   Case 1: Maximizing NPV Let’s say the Fit-It company has a portfolio of ten new proposed projects (see Table 1.3) that require a total cost of $5 billion and could yield $11 billion for NPV. Regrettably, the company is constrained by its annual budget of $3.5 billion and needs to determine which projects to fund to maximize its potential. The first step is to rank or sort the NPV column (see Table 1.4) to find out how far we can go down the list until we run out of budget. We can afford five projects (5, 4, 10, 1, and 3) for a budget of $3.420 billion yielding a portfolio NPV of $7.150 billion.       Case 2: Optimizing NPV The previously described case study is certainly feasible as far as portfolios go, but it may not be optimal. In fact, we may be able to create a better portfolio getting supreme value from the company’s annual budget of $3.5 billion. Using optimization software (developed in-house or purchased), we search for the most efficient portfolio. Optimizing software uses many variables, such as risk, budget, people, current ongoing projects, and manufacturing capacity, to arrive at the best combination of projects. Table 1.5 is an example of using optimizing software (SW). The NPV from Case 1 went from $7.150 billion to currently $7.950 billion for an increased value of $800 million. The new budget of $3.480 billion almost matches the annual budget and the number of selected projects went from five to eight.     Case 3: Profitability NPV Since some executives prefer to see an annual return per project, they could look at the profitability index (i.e. Return on Investment), 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. Of course, the higher the profitability index the better! I have taken the same ten proposed projects used in the previous case and ranked them by their profitability index (see Table 1.6) to get a higher NPV ($7.990 billion) than the one from the previous case described ($7.950). Also, the budget from the previous case went from $3.480 billion down to $3.450 billion, which means we saved $30 million in costs, and at the same time, increased our NPV by $40 million for a $70 million positive spread.     We will pick up next time (in part 2 of my article) by considering how the financial formulas available in MS Excel and Project fit into this analysis. I will also cover several other considerations that should be made when selecting projects for portfolio management. In the meantime, what tools do you use to make project portfolio selections?  

An Agile Attitude: Part 2

An Agile Attitude: Part 2

In Part 1, we looked at the history of Agile and the Waterfall vs. Agile model. Now, I’d like to pick up where we left off and consider how MSP is adapting to more and more organizations implementing Agile. A Short History of Microsoft Project (Or How MSP is Adapting to Agile) Microsoft Project (MSP) has been around since the mid-1980’s and started out as a DOS base project management software product that evolved into a window based product in 1990. Since then, MSP has become the dominant (over 25 million users) PC based project management product used by most organizations. The upgrade from MSP 2010 to MSP 2013 was a major one. The biggest improvement was replacing the text-based reports with graphical reports, which gave project managers an entirely a new way of visualizing project data. MSP 2013 did include an Agile Project Management template as shown in the below graphic, which is found under the File tab (click New). This template is just a starting point for adding sprints and work items, but could be your foundation for developing an Agile project plan. Figure 1.7 shows you a high-level Agile project plan that was generated by using the template from Figure 1.6 which includes resources from Figure 1.1: Agile Roles. The upgrade from MSP 2013 to MSP 2016 was minor in comparison, but did include new timeline updates. Unfortunately, when MSP 2019 came out it was another minor upgrade (e.g., choose a predecessor or successor from a drop-down list) from MSP 2016. I believe these last two updates were minor because Microsoft is focusing more on its Enterprise (i.e., Office 365) applications, as well as project server. The upgrades in MSP 2019 did include upgrades only in project online desktop client with some Agile features and integration with Microsoft Planner. Because of the fast growing popularity of Agile, future versions of MSP beyond 2019 should include many new Agile fields, features, and reports as standard items. The “Sprint” column in Figure 1.7 is a renamed or custom text field that I defined. In the same manner, you can add other Agile related fields like State (e.g., open, closed, done, in progress, or not started) and User Need (setting your priorities or ranking priorities in order of importance). Custom fields are a powerful feature of MSP, and when used with custom groups, filters, and views, you can narrow your focus to what you think is most important at any point in time. Even though Figure 1.7 displays a nice high-level Agile project plan with all the tasks, your Agile project team likely wants to see a snap-shot picture status of their sprints and features to be implemented at least every week, if not daily. This can be done within MSP using Agile-specific information in custom fields allowing you to filter or group specific data and provide different perspectives on the status of your project. All of the text-based defined fields used in Figure 1.8 are as follows: Grouping any MSP data with similar characteristics is easy to do with the Group feature found in the View tab’s Data section. There are many standard groups to choose from (e.g., Critical or Milestones), but we want to create a new group called New Group By. See Figure 1.9, which groups Figure 1.8’s States (Text12) within Sprints (Text13) This is called a Burndown and will produce Figure 1.10, which helps you to better understand and analyze your project information. Implementing APM Implementing APM in most organizations will be challenging for several reasons. Most organizations buy their software developed applications like Microsoft Office, Oracle, or SAP financials, so the main in-house project is implementing the software and training the people to use it. Approximately 25% of all projects within most IT organizations are related to software development (i.e., developing applications from Oracle) and these are usually long-term projects. As a result, the full benefits of APM are limited. This means about 75% of in-house projects are not related to software development and will usually use the traditional Waterfall approach. Insufficient training is the most significant cause for failed Agile implementations within organizations. Agile software development has a set of prescribed rules. Training and practice is required for success. Team members must let go of the idea that the product has to be 100% complete when it is delivered. They must also understand the reality that there’s no end to the Agile learning curve. In addition, creating the Agile transformation is difficult unless organizations and project leaders are truly prepared to make a shift. This could be particularly hard for large matrix organizations. Transitioning to Agile means starting in small steps and being willing to change when necessary. Furthermore, organizations will need qualified people trained in Agile to be coaches, mentors, and to help in the adoption process. An excellent way to start implementing Agile is to bring in a consulting firm that specializes in Agile methodology. Expert coaches and scrum masters can help an organization adopt an Agile strategy that’s right. Keeping the traditional Waterfall development methodology and using APM within the same IT organization or having a “hybrid” implementation organization opens the door for a lot of confusion especially in the areas of controlling projects and measuring successes. Again, this is a great culture change, but having a cross-functional development team for Agile who is committed to the change and will support your organization is vital. The Scrum Master or product owner needs to have real “clout” within an organization. Unfortunately, in most organizations, PMs (leaders) have limited “clout.” You don’t need project management experience to be a Scrum Master (sometimes called a project facilitator), but it helps if you have this background. It gives you a “leg up.” The Scrum Master (see the figure below) is a key role for APM. This person acts as a practice coach, helping the project team, protecting the team from organization distractions, clearing roadblocks, and following scrum values and practices. People assigned to an Agile project team (usually 3 – 9 in number) need to be available 100% of the time and should not be working on other projects. This core team should include the Scrum Master, Development Team, and the Product Owner (customer representative who is the expert on the product and customer needs and priorities). This is a big culture change for most IT organizations and will be difficult to achieve especially if traditional Waterfall projects are being implemented at the same time. Processes are easy, but people are hard! My advice is that APM teams should be collocated (i.e., communicating face to face as shown in Figure 1.11), which means they are working together in a dedicated office area. If a work project room or scrum room can’t be allocated, then cubicle walls will need to come down, so there is single work area for the APM team. Again this will likely be a culture change for an IT organization especially if traditional Waterfall projects are being implemented at the same time. Be ready to buck the status quo going to APM. Some people have vested interests and will be not want to change how they work. APM requires mature behavior. Accomplishments and failures alike belong to the project team and not to individuals. Furthermore, there needs to be an environment of trust and self-management. Earned Value Management (EVM) is a way of measuring project progress, but this is based on an assumed fixed project scope, whereas APM is based on accommodating ongoing scope changes by providing a constant cycle of development, feedback, and change. EVM is used worldwide for mostly large defense or government projects, and private-industry sectors such as construction, energy, and manufacturing. Note, it doesn’t make much sense to force EVM on Agile projects. Summary Agile is not a magic bullet or a cure-all that will make your project run faster than any other one. It’s a real approach with precise rules and roles. It is generally used in short-term projects where the end product is not perfectly described or known at the beginning. It isn’t a way to skip formal project follow-up and administrative management. The risk with an uncontrolled Agile approach is to deliver fewer features than initially scheduled because if, at the end of iteration, the job is not completed or if tests failed, the product scope is reduced for the next iteration to try to deliver something functional. Yes, at the end, budget and time will be respected, but forget the product. Check to see if a real and driven Agile approach is used with key players, with each one in a precise role, and if key project documentation (i.e., product backlog) is maintained. Agile is a good solution for projects that are in development or undergoing major changes with less chance of project failure. For other projects such as those in maintenance mode, Agile is not suitable, but if you are looking for rapid development and tighter project control, Agile can be a great fit for your organization. By adopting Agile approaches, you could achieve increases in product productivity and delivery. The old Agile versus Waterfall debate is fading as many companies learn to be flexible with both delivery approaches in our fast changing world. The consensus is clear – use the right approach for the right project! PMI has many certification types with the Project Management Professional (PMP) being the world-wide favorite. In 2011, PMI introduced a new certification called Agile Certified Practitioner (PMI-ACP). The number of professionals obtaining this new certification has grown dramatically (there are currently over 23,000 holders) because more and more companies are overcoming the above mentioned challenges to Agile and accepting the approach to managing projects. When you purchase the updated PMBOK® guide, Sixth Edition – 2017 (now Agile-aware), you receive a free copy of Agile Practice Guide. This guide was developed as a result of cooperation between PMI and the Agile Alliance.

Implementing Agile – Part 1

Implementing Agile – Part 1

“Implementing Agile can be challenging but rewarding“ Implementing Agile can be very challenging for many organizations (especially in Waterfall development cultures), but at the same time, it can be rewarding. This article covers a short history of Agile methodology, which became mainstream this decade to rev up software development with a faster approach. It defines Agile, its benefits, and covers techniques for using Microsoft Project for your Agile projects. Read on if you’ve ever wanted to make your transition to Agile easier. A Short History of Agile In 2001, new methodology pioneers met in Snowbird, Utah to share their experiences and to suggest ideas for improving the world of software development. They came up with the Agile Manifesto to streamline the development process. According to the Agile Manifesto (2001) : The pioneers also came up with a set of Agile principles, which were broken into four major groups: customer satisfaction, quality, teamwork, and project management. For years, most organizations were very slow in trying the Agile approach, but in the past ten years, they began to have an Agile attitude and its usage has grown exponentially. Why do you think that is? User satisfaction! According to a Standish Group Study in 2015, it was found that 29% of traditional projects failed outright and were canceled, but that number decreased to 9% for Agile projects. I believe this is a direct result of Agile teams making immediate adaptations on frequent inspections of progress. Also, 60% of completed traditional projects were challenged because they had gaps between expected costs and actual costs, time, and/or quality. Agile Project Management Agile Project Management (APM) is a style of project management that focuses on early delivery of business value, continuous improvement of the project’s product and processes, scope flexibility, team input, and delivering well-tested products that reflect customer needs. APM is a lightweight model that uses informal communication style, is fewer document oriented, and uses less rules and practices. In contrast to a heavyweight methodology like the traditional life cycle Waterfall model that describes the various phases in a cascading serial fashion, APM is now becoming a common product development practice that involves building a product with the least amount of features needed (between 1-5) to get feedback for future development. The Agile method easily becomes your blueprint for starting the development process! Agile approaches are a response for the need to modernize project management for small-scale projects where clients have difficulty defining the requirements. The bottom line is that it revs up your software development (i.e., proto-typing) with a faster delivery time and more flexible approach. APM is a great software development approach for software development houses like Microsoft, Google, Oracle, SAP, and web-design organizations. There is no question that APM will increase software development project successes, reduce defects/failures, and increase user satisfaction. 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. APM increases collaboration/ownership between the scrum master, product owner, and development team because they are working closely together on a daily basis. See the figure below for all the Agile roles. The Project Team consists of stakeholders/users that have an interest in the project and provide input. The Scrum Team consists of the product owner and the scrum master. The product owner is a subject matter expert (SME) that knows the business, and customers, and sets the product’s vision and priorities (i.e., roadmap and release plan). This prioritized wish list is called a product backlog. The scrum master is a servant leader or project facilitator who coaches (i.e., provides expertise on Agile processes) the Development Team and protects the team from organizational distractions. Also, this person facilitates consensus-building and stakeholder communications. The Development Team is a hands-on technical group (e.g., programmers, testers, designers, and data engineers) that produces the overall product by pulling a small block from the top of the wish list, a sprint backlog which is derived from the product backlog, and decides how to implement these pieces. The development team usually spends 2 – 4 weeks, a sprint, to complete its work, but meets daily to access their progress (called a 15-minute standup scrum). The real beauty of these short cycles is that the customer gets to see their product as a work-in-process. Scrum is an iterative approach that came from the football game of rugby where a team works closely together on a series of sprints leading to a release of a product or some functionality and takes responsibility for the results. When the next sprint begins, the team chooses another piece of the product backlog and begins the iterative cycle again.   Waterfall Model Versus Agile Agile can lead to higher product quality, increased productivity, customer approval, and team morale. Quality can affect risks because quality management on Agile projects basically reduces risks. Risks usually increase over time using the traditional Waterfall model, but that ratio is the complete opposite when using the Agile. Why? Because short durations or sprints (usually 2 – 4 weeks) prove the product is working. The following figure depicts this comparison and includes the return on investment (ROI). Agile can help increase revenue opportunity sooner and can help the self-funding of future development of new product features. Defining the right development process for your business will have a weighty impact on controlling the schedules, costs, and quality of a product. The Waterfall development model is generally suited for medium to large projects with well-defined requirements. The Agile (or iterative) development model is typically used to develop a product that has not been fully defined. This model is initially used to develop the known requirements. As the overall requirements become better understood and the product is further defined, the next iteration (or sprint) of the product is developed. Each iteration forms the foundation for the next. The fixed and estimated attributes between Waterfall (guess driven) and Agile (priority driven) approaches are completely the opposite as shown below. Also, the Waterfall and Agile lifecycles are shown below. Always remember – whatever development process you use, it must be examined routinely for improvement! Part 2 of this article will be published soon, in which I’ll explore the history of Microsoft Project or how MSP is adapting to Agile. We will also look at implementing the Agile methodology. Stay tuned! References : https://agilemanifesto.org/

  • 1
  • 8
  • 9