Agile Approaches

The term agile is used often these days, but there are still misunderstandings about what an agile project approach is and how it is different from more traditional project approaches. I believe this occurs for three primary reasons:

• The agile approach is still relatively new as a business practice in many circles.

• There are several terms that are used interchangeably with “agile,” including iterative, flexible, adaptive, and extreme.

• It is rarely implemented as a pure methodology.

In most cases, agile techniques are incorporated into more traditional approaches. In fact, many organizational project methodologies are evolving to adopt the agile practices that work well in their environments.

To help your understanding of agile project management techniques and increase your confidence in discussing agile methodologies, let’s do three things. First, let’s review the common characteristics of agile project management approaches. Then, for those who may be in a truer agile environment, we touch base on the key terms used in an agile methodology, and highlight a few practices that will help you become more effective quicker.

To start, let’s run down the common characteristics of agile project management approaches:

• Iterative development—Agile approaches take an iterative approach to the development of the targeted solution. It is an excellent technique when the complete set of requirements cannot be gathered, visualized, or agreed to. In some circles, these iterations are called waves, sprints, phases, or even milestones. Other iterative development techniques can include prototypes, pilot projects, and focus groups. The principle behind the approach is to focus on priority requirements, deliver tangible solutions for evaluation as early as possible, and finish with the desired result.

• Phased deployment—In most cases, agile approaches also emphasize an iterative or phased approach to deployment, techniques that we have discussed before as excellent risk management approaches. Any use of test markets, beta releases, pilot projects, phased implementations, or staged rollouts are examples of phased deployments.

• Detailed, short-term schedules—Agile approaches focus on detailed schedules for the near-term milestone (iteration, sprint, phase, or wave). The schedule for the rest of the project is kept high-level, general, and frequently time-boxed based on historical performances. This is done because the future path of the project is determined (and can be adjusted) based on the actual results and findings of the current iteration. In most cases, an iteration is between 30 and 60 days.

• Customer value–driven—Agile approaches are focused on customer satisfaction. The emphasis is on delivering value, and delivering tangible solutions as early as possible. The goal is to get feedback and clarify requirements as soon as possible. With an iterative approach, the customer stays involved, makes decisions with better data (reviewing tangible results), and remains in control throughout the project.

• Timeboxing—Timeboxing is a trademark characteristic of iterative software development methodologies, but it has use in many project environments and has grown in popularity as a project scheduling technique. In a pure sense, the work requirements (scope) for a given timebox are set (fixed), and little, if any, change is allowed to occur. The time element is strictly enforced, regardless of work completion status. At the end of the timebox, a customer review is conducted to evaluate the results and plan the scope of the next iteration. Requirement priority, refinement of requirements, and progress-to-date all determine the scope of the next iteration. Timeboxing is an effective technique in situations with high uncertainty or situations that need frequent review and evaluation.

• Change expected—This is a core differentiator of agile approaches. Agile approaches expect change and are ideal when the unknowns and unpredictability factors are high.

• Plan-do-review—Agile approaches emphasize the plan-do-review model. Subsequent planning increments are driven by results achieved at the finale of the recently completed iteration, sprint, milestone, or timebox.

• Solution focused—Agile approaches focus on the customer experience and on what the customer is after: the targeted solution. There is a strong results orientation with an emphasis on early value and clarifying requirements based on experience and evaluating tangible results.

• People-focused project management—Agile project management emphasizes the “people” aspect of projects over the bureaucratic, administrative procedures. The focus is on relationships, leading (versus managing), and value. Project management deliverables are limited to the minimal set that offers the most value. Servant leadership principles are a strong fit for agile approaches.

• Collaborative—Collaborative development approaches are another common trait of agile methodologies. There is a partnering arrangement between the customer and the design-development team, and the normal boundaries are minimized, if not removed. Customers are placed on the core team and, in many cases, co-located with the project team. In addition, the iterative development approach emphasizes frequent feedback loops and continuous focus on the customer’s requirements.

• Risk management focused—You can argue that the main purpose of an agile project approach is to manage risk, the key risk being that the final solution will not meet the satisfaction of the customer. The agile techniques of progressive requirement development, short iterations, partnering close to your customers, prototyping, attacking high-risk solution aspects early, and people-focused management all contribute to managing this essential risk.

Next, if you happen to be working in a truer agile development environment, let’s review a few key definitions that will help accelerate your learning curve and effectiveness:

• Sprint—A timeblock (timebox) for development. This time period is normally 2–4 weeks.

• Epic—Major items (group) of scope. Think of this as a functional area of the system or key process workflow.

• Stories—Aspects and/or components of an epic. Use cases or function points would be similar concepts.

• Tasks—Specific work items needed to accomplish (develop) a story.

• Backlog—The inventory of prioritized work items for the project. This will include the original features (stories, tasks) to be developed, plus defects found during testing and enhancements identified during the process.

• Daily standup—The daily checkpoint meeting during a sprint. It is time-boxed at 15 minutes and held at the same time each day. It is meant to encourage communication, sharing, and accountability. Each participant provides a concise update addressing these three questions:

  • What did you do yesterday?

  • What will you do today?

  • Are there any obstacles in your way?

• Retrospective—The review meeting held at the end of a sprint for the purpose of continuous improvement. This checkpoint allows for early identification of anything not meeting expectations or agreement on the corrective actions to take to improve performance in the next sprint.

• Scrum—One of the most popular ways to implement an agile methodology for software development. It is an iterative software model that follows a set of roles, responsibilities, and meetings that never change. Sprint development cycles are used to deliver software on a regular basis.

• XP—The acronym for another type of agile software methodology called extreme programming. It is similar to Scrum, because they are both agile-based approaches, and frequently project teams will adapt elements and practices of both methodologies. The key differentiators of XP include use of 1-week iterations (versus 2–4 week sprints), a strict adherence to developing scope in priority order, and emphasis on software engineering practices like test-driven development, automated testing, and pair programming.

Now that we’ve hit a few key terms, let’s next talk about a few practices that will help you manage an agile-based project:

• Leverage skilled SMEs—To support the tight time frames and need for quick decisions, it is imperative that the business assign skilled subject matter experts (SMEs) to the project team. Without them, there will be gaps and negative impact to the development process.

• Use the right tool—Whenever possible, leverage a software development process and management tool that is designed for agile development. This will make it easier to implement the agile processes and ensure a higher level of communication among the team.

• Clarify big-picture scope—While agile approaches are great tools for situations when scope details are ambiguous or the customer is not sure what they want, it is still important to clarify and define the big picture as soon as possible. Ideally, when the initial definition phase of the project is complete, you will have a comprehensive list of stories that define desired functionality, the integration points, both internal and external stakeholders, and any key dependencies. The better the definition of the scope boundaries and key function points is up front, the better the estimates can be, the better alignment of epics and stories within a sprint, and the better the sprint plans will be overall. Without this, there is a higher probability of project delays, sprints completing with planned work not done, and rework of previous developed scope.

• Determine the sprint duration—When deciding what sprint duration your project will have, you need to balance how frequent progress needs to be displayed to the stakeholder, the experience of the project team, the capacity of the development team, the estimated work efforts of the key stories, the tolerance for outstanding defects, and the overhead impact of supporting processes (testing, code reviews, and so on).

• Allocate a sprint(s) for requirement refinement—Because the nature of agile development encourages early and frequent reviews and refinement of business requirements, it is essential to allocate at least one sprint in your plan for this refinement to be developed (especially if it must have features for the initial version of the product).

• Allocate a sprint(s) for planned work rolled back into backlog—It is a good idea to allocate at least one sprint in your plan to address the work that was not completed as originally planned in earlier developments. In most cases, because work planned in early sprints usually includes high-priority items, that work normally gets reallocated to the next sprint. This results in a cascading impact to the scope of future sprints unless development capacity is increased to help compensate.

• Allocate a sprint(s) for test defect resolution—In a similar vein, there will be test defects identified during the sprint that might not be resolved within the sprint. These outstanding defects will be added to the backlog and must be prioritized along with every other item in the backlog for future sprints. In most cases, you will need a sprint focused on test defect resolution before the product is deployed to production.

DevOps and DevSecOps

For those working in the IT space, especially with application/software development, you are most likely to come across the growing trend of DevOps and DevSecOps…and that is almost a guarantee if you operating within an agile environment. So, let’s cover what these terms mean, why more organizations are adopting these practices, and the key focus areas for the project manager.

While agile development was born out of a desire to build applications faster and tear down the walls between development and the business, DevOps practices were created to do the same between development and operations. Hence the term “DevOps” is a merger of the terms Development and Operations, and the practice of DevOps is a natural extension of agile development.

In a DevOps culture, DevOps is a set of practices that combines software development and IT operations. It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. It provides tighter alignment and collaboration between once siloed roles and strives to avoid the handoffs and the deployment and sustainment issues that are common in the traditional approach. In short, it moves the Operations function to the left in the life-cycle process flow and embeds the Operations personnel within the project team.

In a mature DevOps culture, you will see applications developed, tested, and deployed faster with minimal issues and defects and with a better ability to monitor the health of the application in production. So, you might be asking, “Well, if this is true, why aren’t all organizations using DevOps already?” Well, that’s because you are dealing with major organizational change management and in most cases a whole new set of tools and way of working.

To make all this happen, one key aspect of DevOps is to automate as much of the IT workflow as possible. This requires a new set of tools, new way of architecting applications, new knowledge, new roles, and new approaches to the work. The focus areas of DevOps include, but are not limited to, source code management, code builds, continuous integration, continuous deployment, testing, configuration, and performance monitoring. And when we discuss DevSecOps, the focus areas also include security tools for continuous threat and vulnerability management. The number of available tools for each automated function is lengthy, but common tools you are likely to encounter include, but are not limited to, GitHub, Jira, Docker, Kubernetes, Jenkins, Maven, Ansible, Nagios, Splunk, JUnit, LoadRunner, and GitLab.

As you can imagine, since DevOps is a relatively new methodology (a set of practices), there are new tools to acquire, learn, and adopt, and every industry and organization has its own unique set of change management challenges—the level of DevOps maturity and implementation varies greatly within organizations at this point in time. Not unlike the shift to agile approaches, it is common to see a lot of hybrid approaches as organizations make this transition.

Before we review what this all means to the project manager, let’s review DevSecOps in more detail first. As you probably guess by now, the term DevSecOps is a merger of Development, Security, and Operations, and the methodology resulted from some of the shortcomings of DevOps. In a strict DevOps culture, you could still end up with security testing not being part of the main workflow and security risks not being identified until later in the life cycle when the time and cost to resolve can be exponentially more. Thus, DevSecOps fulfills the desire to integrate security concerns and security testing (automated security testing ideally) into every phase of the development life cycle. Again, like DevOps, it moves the Security function to the left in the life-cycle process flow, embeds the security personnel within the project team, and includes a new set of tools, technologies, and approaches.

But other than the security component, DevOps and DevSecOps have a great deal in common and share these features:

• A culture of collaboration and communication among once siloed groups/functions

• Shared responsibility across the team for application performance and security, especially the developers

• Focus on faster delivery

• Transparency of work

• Maximize automation—reduce, if not eliminate, any manual development, operations, testing, and performance monitoring tasks

• Maximize customer value

• Monitor and measure performance and health of systems and software

• Capture feedback and continuously improve “the system”

Okay, at this point, you might be saying, “This all sounds very technical; why do I, as a project manager, need to know about this?” Well, much like with agile approaches, to be more effective, you need to understand the work process your team is using and the tools involved. Specifically, here are the key focus areas for the project manager working in a DevOps or DevSecOps environment:

• Servant leadership to foster the collaboration/trust needed and handle the change management aspects involved in your organization

• Need to understand the processes involved to properly plan, define roles needed, understand the dependencies, and ensure processes are working

• Use the same tools the team is using for work tracking and communication

• Ensure feedback and defects are captured and incorporated in replanning efforts

• Ensure automated testing is kept current

• Ensure continuous integration/continuous deployment (CI/CD) workflow is functioning as expected

• Remember that automation is a component of DevOps and DevSecOps, but not the only component

HIPAA, Privacy, and Security

At one time, privacy and security were of concern primarily to national defense systems and financial institutions. Now all systems must have privacy and security concerns embedded within not just the system requirements, but also within all aspects of the team and organization, including physical location of the team, team procedures, testing procedures, tools used, and communication methods allowed.

The Internet and most applications developed in the past few decades were not developed with security in mind, nor with awareness of how their systems could be exploited and how customers’ data could be stolen. Well, those days are over. Now, due to federal requirements, serious financial liability concerns, and demands from the marketplace, organizations and systems must be more focused on systems security and data privacy. Although we could spend an entire book (or two) on this subject matter, what I want to do in this section is provide some guidance to the project manager who might be new to all of this. These notes will enable you to conduct an intelligent conversation about these matters and, more importantly, help you ask the right questions when you are planning and executing your project.

To start, here are the definitions for three common acronyms:

• HIPAA—The Health Insurance Portability and Accountability Act, passed by Congress in 1996. The act accomplished several things, but for our focus here, it requires the protection and confidential handling of protected health information. In particular, it ensures only the minimum information necessary is used or shared.

• PHI—Protected health information, as defined in HIPAA. As a general rule, PHI covers any information for past, present, and future medical conditions, including patient identifying information and payment provisions. It applies to all forms of this data: paper, oral, and electronic.

• PII—Personally identifiable information, any information that can be used to uniquely identify, contact, or locate an individual, or can be used with other sources to uniquely identify a person. While part of HIPAA, PII has become a focus for all systems doing business on the Internet.

Here are some things to consider when dealing with HIPAA, privacy, and security:

• Get educated—As a new project manager, understand which privacy and security standards are important to the organization and which standards must be met so that your project is accountable. In addition, clarify what training your team must complete to ensure adherence to these standards.

• Set up projects with security in mind—You need to ensure the following:

  • Access to any system and project resource is individually authenticated.

  • Access to the physical location(s) of the project is secure.

  • Any remote access by team members is secure.

  • Any tool used supports the necessary security protocols.

  • All project team communications abide by security protocols.

  • All team members know what to do if any device is lost or stolen.

• Design your system with security in mind—The days of “open” default access are over. Systems must be defined with encrypted channels as the preferred choice. The proper audit trails and checks should be built in to the system.

• Protect production data at all times—Protect the need to access any production data during systems development and testing. If it must be done, ensure access is limited and any key PII data elements are masked. Focus on limiting any printout of this data.

• Plan for security audits—Assume your project will be accountable to security audits. These audits will likely target physical locations, networks, applications, procedures, systems access, and especially any area where the organization has been exposed before. Plan not only for the audits, but for time and resources needed to analyze the audit results and provide action plans to remediate any gaps.

• Plan testing with security in mind—Not only do test plans need to ensure the targeted business and functional requirements are met, but they also need to take a hacker mentality and include test cases and/or testing tools that will proactively identify any data privacy or security holes.

Project Management Offices

The nature, scope, and overall effectiveness of a given Project Management Office (PMO) vary from organization to organization. As a result, perceptions of the value that a PMO offers vary widely, and there is a lack of consensus on what a PMO is supposed to do. As a project manager, you must be clear on the responsibilities that your PMO has, how it can assist you on your project, and how you need to work with it during your project. In many situations, your PMO reports are separate and distinct from your status reporting and implemented as an individual line item on your communications plan.

To start, the organizational scope of a PMO can vary tremendously. Some of the first PMOs were developed to manage enterprise projects, such as enterprise resource planning (ERP) implementations. Since then, the scope of PMOs has expanded. In some organizations, the PMO is at the corporate, enterprise level. In others, it is positioned at the business unit or department level. The level is often determined by organizational culture, stage of PMO evolution within the organization, and organizational priority.

In either case, the nature and authority of the PMO fall somewhere on a spectrum. On one end of the spectrum is the support mode. In support mode, a PMO provides project managers with training, guidance, templates, and best practices. On the other end of the spectrum is the central planning, project oversight mode. In this mode, the PMO provides all the project managers, controls the portfolio management process, manages resource allocation, and closely monitors the performance of each project. In addition, the scope of a PMO is not always limited to projects. In some organizations, PMOs are used to monitor and oversee service-level agreements (SLAs) with vendors. Specifically, the responsibilities of a given PMO are a combination of the following:

• Project support—Provide project management guidance to project managers in business units.

• Methodology—Develop and implement a consistent and standardized project management process.

• Training—Conduct or outsource project management training.

• Consulting and mentoring—Coach employees on best practices.

• Tools—Select and administer project management–related tools for use by the organization.

• Program management—Provide management and oversight of multiple, related projects.

• Portfolio management—Establish a process for requesting, prioritizing, and approving projects. In addition, establish a process for canceling projects that are not meeting portfolio performance standards.

• Resource management—Establish and execute processes to ensure resources are allocated effectively based on the portfolio priorities.

• Monitor SLAs—Monitor performance of and adherence to service-level agreements.

Historically, most PMOs were started by CIOs to provide the needed structure to standardize project management practices, facilitate IT project portfolio management, and develop methodologies for repeatable processes. Today, the best PMOs leverage the organization culture to successfully deliver the project portfolio in a way that satisfies both senior management and the targeted customers. By enabling better resource management, reducing project failures, and supporting projects that offer the biggest return on investment, PMOs can provide the foundation for effectively managing any business.

The specific organization and staffing model for a PMO depends on a myriad of organizational factors, including key organizational pain points, targeted goals, natural organizational strengths, strengths of existing resources, and corporate culture.

Portfolio Project Management

Portfolio project management (PPM) describes various approaches to managing projects as part of an overall project investment portfolio. PPM focuses on project initiation (determining which projects should be funded), aligning projects with corporate strategy, aligning resources with those project priorities, and monitoring performance of the project portfolio throughout the year. The practice evolved out of the growing reality that more and more business is accomplished through projects, the concern that too many projects did not succeed, and the lack of visibility that many executives had on ongoing project performance.

Here’s a list of additional insights and observations to help you better understand portfolio project management topics:

• Portfolio project management is NOT program management—This is a natural point of confusion due mainly to the terms used and to the role of many PMO organizations. Portfolio project management is focused on the investment aspect of the project funding decisions. Program and project management is focused on the delivery (execution) of those projects in the portfolio.

• Never be totally objective—Implementing portfolio management is political by nature. Most PPM advocates emphasize the dimension of objectivity and the focus on quantifiable metrics introduced into the project request evaluation and approval processes for an organization. To their credit, PPM processes do reduce the degree of political influence. However, people make these final decisions and the profit centers still carry tremendous influence in determining what projects are funded.

• Element of corporate governance—In many organizations, project portfolio management is closely tied to the corporate governance process. The senior management (or executive) group that determines the project portfolio is the same group checking project performance status on a periodic basis.

• PPM software—A full PPM solution manages demand (work requests) and resource allocation, prioritizes requests, and monitors investment performance.

• May or may not include resource management—Some organizations include resource management as part of PPM while others do not. This is something to clarify when starting in a new organization. If it is not included, there should be tight integration with the corporate resource planning and allocation processes.

• Separate reporting process—In most organizations, the status reporting you do for your PPM tool and the corporate governance process is different than what you do for the project leadership team. This occurs because of the limitations of the PPM tool and because of the amount of detail that the executive committee wants to see. From the advancements I see in PPM solutions and the current state of many web-based project management software offerings, I think this will change in the future.

• Finding the balance—You must find balance for your given organization. Although most senior management types do not want (nor have time for) the details of your project, they also do not want to be surprised. They do not want to see a project “green” (it’s going great) one reporting period and then “red” (help me, I’m in big trouble) the next. This is one of the main advantages of exception-based or stoplight-based status reporting approaches. From my experience, I tend to go “yellow” on any dimension with a high-impact risk or current issue.

Governance Processes

Okay, corporate governance is not exactly a hot (or new) concept, but it is a term that gets thrown around a lot and is often not explained to people who are new to the scene. Because it is closely associated to PPM and PMOs, I thought it would be helpful to put this concept in proper context, too.

Here are a few insights and observations from my experience that can help you better understand corporate governance topics:

• Portfolio project management is part of corporate governance—This is discussed in the previous section.

• Other elements of corporate governance—Corporate governance can include more than just project portfolio management. In most cases, the additional governance scope is needed to ensure compliance with strategies, standards, policies, and regulations. Specifically, other corporate governance processes can include the following:

  • IT governance (compliance with architectural standards)

  • Procurement

  • HR

  • Resource management

  • Legal

  • Regulatory

  • Quality assurance

Critical Chain Project Management

Critical chain project management (CCPM) is a management practice beginning to gain momentum. As a relatively new project manager, you might find yourself working in an organization using CCPM, or you might be hearing more about it and just wondering what is so different about it. My objective is to give a brief synopsis of CCPM, clarify the key unique features, and provide a basis for further discussion and discovery.

CCPM is a method of planning and managing projects based on Eliyahu M. Goldratt’s Theory of Constraints. It is a method that emphasizes resource management and speed. It is a method that aims to remove the slack that is built in to most schedules. It is a method that requires a different approach to schedule development, project execution, and monitoring project performance. Let’s take a closer look at some specific features to help you better understand the principles and uniqueness of CCPM:

• Critical chain—CCPM identifies and focuses on the critical chain, as opposed to the critical path. Resources are then assigned to each task, and the plan is resource leveled using the 50% estimates. The longest sequence of resource-leveled tasks that leads from the beginning to the end of the project is then identified as the critical chain. If there are no resource constraints (and resources are leveled), then the critical chain and the critical path are the same.

• System—In CCPM this term refers to all tasks in the schedule.

• Two estimates for each task—When estimating the work effort or duration for a task, two estimates are developed. One estimate is called the 50% probability estimate; the other one is the 90% probability estimate. The 50% probability means exactly that; the task has a 50% chance of completing within the effort and time estimate. The assumption is that most schedules are based on 90% probability estimates.

• Schedule on the 50% probability estimate—A CCPM schedule is built based on the 50% probability estimates. The justification for using the 50% estimates is that half the tasks will finish early and half will finish late, so that the variance over the course of the project should be zero.

• Pool the differences into a buffer—The difference between the two estimates are pooled into a buffer, called the project buffer. This buffer is added to the end of the project schedule to protect the targeted completion date.

• Feeder buffers—In addition to the project buffer, CCPM also uses a series of feeder buffers to further protect the critical chain. Any noncritical chain task that feeds into the critical chain sequence has a buffer, a feeder buffer, inserted between the noncritical chain task and the critical chain.

• Resource focus—CCPM is focused on resource constraints and resource productivity. You will read and hear a lot about “throughput.” It is a requirement that schedules are resource leveled in order to reduce, if not avoid, multitasking.

• Resource transition—The CCPM references discuss a third buffer type—a resource buffer. This is a bit confusing, because it is not a buffer in the same sense of the project buffer and the feeder buffers. The resource buffer focuses on project execution and on the process of transitioning a task sequence from one resource to another. The process involves direct communication between the resources (performers) assigned to the two tasks. The predecessor task resources notify the successor task resources on regular, predetermined intervals about their expected completion date. Furthermore, a final confirmation should be given a day or two before task completion so all successor task performers are ready to start work exactly when needed. Goldratt calls this notification process the resource buffer. It is a simple, yet effective method to ensure that a task starts exactly when it should. Early finishes are not wasted.

• Relay runners—As hinted at in the previous section, the mode that resources operate in a CCPM project is that of a relay runner. The resource knows when the baton is coming (predecessor task completed), as soon as the baton arrives the resource stays focused and gets the task completed as fast as it can, and then hands off the baton to the next runner (resource assigned to successor task).

• Efficiency of pooled buffers—This is a strong component of CCPM. By pooling the usual slack found in task estimates into buffers and setting up task management procedures that encourage and reward speed, a project can take advantage of the time gains that would normally be hidden or eaten up from multitasking, student syndrome, Parkinson’s Law, inbox delays, lack of prioritization, or task handoff inefficiencies. If any particular task is delayed or completes later than the 50% estimate, the project manager “borrows” time from the project buffer and adds it to the offending activity. On the other hand, if an activity finishes early, the gain is added to the project buffer.

• Monitor the buffers for project health—Overall project health is measured by monitoring the feeder and project buffers. If the rate of buffer consumption is low, the project is on target. If the rate of consumption is such that there is likely to be little or no buffer at the end of the project, then corrective actions or recovery plans must be developed to recover the loss. When the buffer consumption rate exceeds some threshold value (a rate that puts the buffer at risk of being consumed before the project is complete), then those response plans need to be implemented. CCPM advocates feel that buffer management is better than earned value management (EVM) for measuring project performance because the EVM technique can be misleading. EVM does not distinguish progress on the project constraint (the critical chain) from progress on nonconstraints.

Web-Based Project Management and Collaboration Tools

If your project requires (or could benefit from) sharing project information with clients, vendors, subcontractors, a mobile or geographically dispersed team, or anyone located outside your corporate networks, you should consider web-based project management and team collaboration software solutions. The purpose of this section is to make sure you are aware of those options and to offer some recommendations on what to consider when evaluating them.

To start, some of the attractive features of these tool options and the reasons you want to consider them include the following:

• No software installation required except your web browser (that is, cloud-based).

• Web-based solutions can be much less expensive. Depending on the features you require and your ability to leverage open-source options, a web-based solution can even be free.

• Ability to update tasks and project plans from anywhere.

• Ability to establish a centralized, private, secure environment connecting people, process, and product regardless of team member location.

• Provide for better visibility and openness.

• Streamline communication and work effort.

• Can assign tasks to individual team members and track progress.

• Can be deployed within a day, depending on need and licensing arrangement.

• Most vendors offer Software as a Service (SaaS) models.

• Many vendors offer hosted or installed “on premises” options for environments that have tight security requirements.

• Faster and enhanced working processes.

• Short learning curves.

• Most offer group discussion/chat capabilities.

• Most offer version control of project documents.

• Most offer web conferencing tools.

• Can serve as project repository—easy to locate documents and artifacts; keeps documents current and synchronized.

• Reduce the need for email collaboration and the challenges that can come from that, especially when multiple team members are reviewing the same artifact or responding to the same topic.

Many options are available now, and the list continues to grow. If you can consider web-based solutions, here are key elements to consider in your selection and evaluation process:

• Project management feature set required

• Enterprise visibility

• Cost

• Return on investment

• Ease of use; training required

• Platform independence

• Scalability

• Integration ease

• Ability to focus on work and not status reporting effort

• Level and granularity of security needed

• Ability to use for client access

• Disaster recovery services offered (backups or prevention of data loss)

Requirements Management Tools

The purpose of this section is make sure you are aware of requirements management tools and to provide criteria to help you determine whether your project or organization needs to consider using one.

First, a requirements management tool is a centralized, collaborative, and database-centric approach to managing requirements, versus the document-based approach that has traditionally been used to capture, communicate, and review the specifications for a project or product.

In many environments, simply moving the document-based approach to a project team collaboration tool can alleviate many issues. However, there are many cases when even that might not be enough. To determine whether your project or organization could benefit from a requirements management tool, consider these factors:

• The complexity level of the targeted product or solution

• The size of the stakeholder team participating in the requirements definition process

• The need for multiple people to modify the same set of requirements simultaneously

• The change frequency level of the requirements

• The efficiency and effectiveness of the requirements review process

• The need and ease of tracing source requirements to design specifications or test cases

• The need to integrate requirements with a test management tool

• The need and ease to link to related and supporting requirements

• The need to store a common set of attributes about each requirement

• The need to manage requirements that are planned for different releases or products

• The need to reuse or access the original product/solution/system requirements for future enhancement projects

• The need to store requirements that were deprioritized or rejected

• The need to reuse requirements for future projects

Mind Mapping Tools

Mind mapping software allows you to build, modify, and share mind maps electronically. A mind map is a diagram that contains information pieces (words, ideas, pictures, tasks, and so on) arranged radially around a central theme (key word or idea).

A mind map enables you to do visual thinking. It enables you to capture and communicate related information in a manner that is aligned with how the brain organizes data and information. Mind maps have been used successfully in brainstorming environments to generate, visualize, and structure ideas. They have also been used as powerful aids in learning new concepts, note taking, problem solving, decision-making, and writing. I have provided basic, simple mind maps at the end of each chapter using the MindManager tool from Mindjet (www.mindmanager.com).

So, why do I include this in a project management book? Why is the use and acceptance of mind mapping tools growing rapidly? Why are more and more organizations adding mind mapping tools to their productivity tool arsenal? To help answer these questions, let me offer these insights based on my own experience:

• Ability for one-page communications—The ability to communicate large amounts of information and the most complex concepts on a single page in an easy-to-understand manner is powerful.

• Visual appeal—There is a “wow” factor. It’s different, but at the same time more natural for many audiences. It catches your attention and draws you in.

• Collaborative nature—It was built for collaborative work sessions. For a project manager, it is a powerful medium for planning a project.

• Integration power—Mind maps provide a portal-like home base for all documents, deliverables, or artifacts associated with the subject of the mind map. In addition, the best mind mapping software provides for easy integration with your other productivity suite software (such as Microsoft Office and Project).

• Streamline paperwork—Due to the organizational power and visual appeal of mind maps, you can effectively share and communicate information simply by sharing the mind maps. There is a reduced need for additional documents to be created.

• Working smarter—As the pace of work increases and the nature of work becomes more collaborative, organizations and knowledge professionals continuously look for ways to work smarter and be more productive. Mind mapping tools can facilitate these goals.

Value of Certifications

This is always a hot topic, and not just in the project management circles. What is the value of certifications? What does having one mean? What does it really measure? These questions are fair, especially in a profession like project management that requires skills and talents that are difficult to measure in standardized testing approaches. The most popular project management certification is the Project Management Professional (PMP) from PMI. It is the gold standard for a project management professional certification. In addition to the PMP, PMI offers a number of other certifications and micro-credentials. Since the last edition of this book, PMI has added four new certifications focused on agile/hybrid project approaches. See Table 25.1 and Table 25.2 for a summary of PMI’s offerings as of 2021.

In addition, for those of you focused on agile/hybrid projects, there are other industry standard certifications that are highly regarded. Primarily, the certifications offered by the Scrum Alliance (www.scrumalliance.org) and the Scaled Agile Framework (SAFe) certifications from Scaled Agile, Inc. (https://scaledagile.com).

Okay, I might not be the most objective person in the world, because I am a PMP, but I think I can offer helpful insight on the value of project management certification:

• Get serious—By earning a certification, you demonstrate a mindset that says to others that you take your work and your profession seriously.

• Common understanding—A certification does not guarantee performance or results, but it does ensure that you share a vocabulary and a common understanding of fundamental project management processes.

• Differentiator—In a competitive marketplace, any method to further differentiate yourself from your peers never hurts, and earning a credential is good way to do that.

• Marketability—More and more employers are using the PMP credential as a base requirement for their project management positions.

• Compensation—Studies have shown that the average compensation level of certified professionals is higher than their uncertified counterparts.

Project Management Training

When it comes to project management training, a wide variety of options is available. In the same way it can be difficult to test for project management skills, it can be equally challenging trying to train someone to be a project manager. From my experience, here are a few insights and observations I’ve accumulated over the years on project management training:

• Mentoring—The absolute best way to learn project management is to observe it being done well. When possible, newer project managers should serve on a project team with a more senior project leader. This could be as a project manager with a senior program manager, or it could be as a project coordinator, a project administrator, a business analyst/lead (if skill set applies), or as a technical lead (again, if the skill set applies) with a senior project manager who enjoys the opportunity to mentor others.

• Focus on specific skills—Another worthy training strategy is to focus on one skill set at a time. In most cases, professionals have specific areas they need to improve, and often when these skills are improved, it will have a cascading effect on other areas of performance.

• Simulations—Given the nature of projects, it is difficult to anticipate the specific situations and scenarios that a project manager will face or to bring the reality of projects to the classroom environment. Due to the improvements in technology over the years, a tremendous advancement in training is the use of computer and gaming simulations. I am convinced this is the future for all training efforts.

• Computer based—I find computer-based, web-based, virtual training offerings (webinars, online seminars, and so on) to be an efficient and convenient method for staying informed on current trends and tools and refreshing key fundamentals.

• PMI special interest group conferences—I have received a lot of benefit from attending the educational conferences provided by the PMI special interest groups. I believe the main reason for this is the presentations are provided by practitioners from the field and the content is very current and relevant.

• Skills to target—As you gain experience in project management and attain a certain mastery of the project management fundamentals, it can be more difficult to find project management training that offers a lot of value to you. Well, one of the great things about project management is that it covers almost all aspects of business, management, and your industry, so there is never a shortage of things to learn about or improve upon. For most people, there is value in acquiring additional training in the following areas:

  • Business management

  • Procurement

  • Leadership

  • Quality techniques

  • People management

• Tool-specific—Especially tools used for project management, communication, and collaboration.

The map in Figure 25.1 summarizes the main points reviewed in this chapter.