Can any dry textbook definition truly describe the project of climbing Mount Everest for the very first time? Or a project to find new sea routes in uncharted seas?

Yet, when you observe projects in real life a little more closely, you will see a lot that is familiar about them. Big or small, high-risk or no-risk, personal or mega-scale, there are some specific parameters that unify every project.

Project – the definition

In everyday life, projects of every size, budget, risk, and complexity can be found, but here is a definition that defines the soul of a project:

"A project is a temporary and unique endeavor with defined objectives."

While this definition is as generic as it can get, there are some crystal-clear points to break down:

• Temporary nature: Projects are temporary in nature – there has to be a clear, time-bound start state and end state. Projects cannot go on forever.
• Uniqueness: Pay special attention to this word; it says a whole lot about projects. Manufacturing cars is not a project (because mass-manufactured cars are not unique); it is more of an operation. Similarly, providing a car wash is a service. However, setting up the factory where cars are mass-manufactured is indeed a project.

  Moreover, exactly because projects are unique, they often face more unknown factors. The customer's reaction to a new shoe may really be unknown; a newly engineered door on the Mir space station may not function properly because the conditions cannot be 100% replicated during engineering. Often called unknown unknowns, this risk with projects is widely acknowledged and implicitly understood.

  We will discuss risks several times in this book, and how Microsoft Project can help with risks associated with schedules, resources, and budgets.

• Endeavor: Projects are purposeful by nature. They don't happen by accident. Or rather, accidental happenings are not called projects. The word endeavor also implicitly means that something has to be accomplished.
• With defined objectives: This means both the result and the limits it must be achieved within. For example, if you are building a house, you will expect to finish it to an acceptable quality, in a reasonable timeframe, and within a limited cost.

  Note

  Definitions in this book are not the official or standard definitions. It is my humble attempt to make the definitions as easily understandable and memorable for the reader. For the most definitive reference to all the terminology used in this chapter, please consult Project Management Institute's PMBOK® Guide (A Guide to The Project Management Body of Knowledge). In fact, this chapter is based upon this widely accepted standard.

Project management

Project management is the art and science of achieving project objectives by applying knowledge, tools, and techniques.

The science aspect of project management is derived from the body of knowledge. And the art aspect of project management becomes evident depending on how you apply the available knowledge to your project in your unique situations. This is because there is no single way to execute a project; and the execution is approached based upon the collective wisdom and other resources of the team. Therein lies the art of project management.

Microsoft Project is the preferred software tool. With the scheduling aspects of your project, it can prove to be the most important software project tool that you will use.

Project management done correctly can help you do the following:

1. Achieve your business' end goals
2. Manage constraints in the project – scope, quality, and costs
3. Increase predictability – even for subsequent projects
4. Optimize the usage of precious resources – money, people, machinery, and materials
5. Recover projects in trouble

The application of good project management practices and Microsoft Project will greatly enhance the success of your project.

Pitfalls

A common beginner's pitfall is to use MS Project only to create a schedule. The new user starts enthusiastically, and might even create a schedule at the beginning of the project. But they will not know how to use it to track the project, how to leverage one-click dynamic reports, how to identify risks, or for the long list of other features.

By reading this book, you will identify Microsoft Project's role in all major process groups that you will perform as a project manager.

The project manager

The project manager is the person around whom the project universe revolves. They are directly responsible for the success of the project.

To accomplish such a responsibility, the project manager is expected to bring a great deal of skills and competencies to the table. Project management skills are always expected: awareness of best practices, domain knowledge, business analysis skills, industry standards, and regulatory policy knowledge are just some of the fundamentals. If the project manager also has technical skills, they are highly valued.

Amongst the so-called soft skills, people and organizational leadership skills, good communication, conflict management, administration, and general management are just some of the fundamentals.

Moreover, this is a field where experience can make a big difference to project outcomes and is valued at a premium.

As we understood earlier, today, there are multiple global standards for project management. Each of these methodologies provides a holistic set of guidelines, practices, tools, and techniques in self-contained packages.

These methodologies have evolved to cater to different sectors, business domains, geographies, and engineering practices. Organizations that specialize in executing projects, and for whom project success is business critical, will adopt one or more of these methodologies.

Choose your fount of knowledge

Some of the most popular methodologies are the following:

• Project Management Institute (PMI)'s – A guide to the Project Management Body of Knowledge (shortened to PMBOK and pronounced pimbok) is a globally recognized standard and is widely used across industry domains. This book will draw upon the PMBOK Sixth Edition.
• The International Organization for Standardization (ISO) has several standards published, notably ISO 9000 for Quality Management Systems in Projects and ISO 21500:2012 – Guidance on Project Management
• PRINCE2 (Projects in Controlled Environments) is popular in the UK, some European countries, and Australia. This originated in the UK for government usage, and today is also a globally recognized methodology.
• New kids on the block: Relatively recently introduced and originating from the software and information technology worlds, there are several other methodologies that are adaptive, iterative, and incremental in nature.
• Agile and Lean are a couple of the most popular ones in global usage. These methodologies are slowly making inroads into broader acceptance in other fields.
• Hybrid and customized methodologies are also being elaborated and practiced, especially in emerging markets and technologies. These take the best of the predictive and agile methodologies and tailor them according to specific project requirements.

So, what is the bottom line?

• Companies will usually adopt and adapt one or more methodologies, based upon their business domain, customer demands, go-to-market constraints, regulatory guidelines, and other requirements.
• Even with the established traditional methodologies, there is now wide recognition of adaptive frameworks. In fact, PMBOK Sixth Edition is packaged with the Agile Practice Guide included.
• Microsoft Project, starting circa 2017, has started providing some capabilities to support Agile, Kanban, and Hybrid, though widespread adoption by users remains to be seen.

The project life cycle

Since projects have a start date and an end date, the intermediate period (between those two end points) can be described as the life of a project. But in reality, the project manager's role and involvement will usually exceed even the closure of the project, for example, usually in the financial and support aspects.

The duration of all projects, irrespective of size, can be described as a series of phases that together make up the project management life cycle. This describes the stages of development the project passes through to reach completion.

Here is a graphical representation of the project life cycle:

Figure 1.1 – Project life cycle

The phases can be stated as follows:

1. Starting the project
2. Planning, organizing, and preparing the project
3. Executing the project on schedule
4. Completing the project

While the sequencing direction is implied in the diagram, some of the phases can be iterative depending on the nature of the project.

Project management processes

The project manager will execute a large set of activities during the life cycle of a project. These simple activities can be logically grouped together as the Project Management Process.

The following diagram depicts a generic Project Management Process:

Figure 1.2 – Representation of a generic project management process

As we can see, a process consists of a set of prescribed tools and techniques applied on some inputs and producing expected results as outputs.

For example, Develop Project Charter is one of the very first standard processes, performed by the PM once in the project life cycle. Similarly, Acquire Resources is another process, albeit performed on a need basis – as and when required. Another example, Monitor Communications, expectedly happens throughout the project life cycle – and many times.

Tip

How many project management processes are there? The current PMBOK Sixth Edition lists 49 processes. The number will vary depending on what methodology and version you reference. The semantics may vary but the philosophy will remain the same.

Every single project management process can be conveniently categorized under two different classifications: as Process Groups and as Knowledge Areas.

Project management process groups

You, my astute reader, might now have extrapolated that individual project processes themselves can be logically grouped – and this is correct.

Before we proceed with understanding process groups, here is a note of caution. A common pitfall is to confuse process groups with project phases (or the project life cycle). You will soon see why such confusion can be prevalent.

Here are the process groups:

• Initiating Process Group: Whether it is the start of a new project or a new phase within a running project, initiating processes are performed. These help in defining the project or phase.
• Planning Process Group: All planning processes are grouped here – including the scoping of the project (or a phase). Create WBS is an important process in this group and we will learn more about it later in this chapter. Every time there is a change in the project requirements, this group will get activated at any point in the project life cycle.
• Executing Process Group: Processes in this group deal with the execution of the project. Providing direction for the project, managing quality, building out a project team, and acquiring resources for them – all these are processes within this group.
• Monitoring and Controlling Process Group: The processes in this group help the project manager ensure that everything runs according to plan – and within project tolerances. The control of the cost and schedule are some of the important processes within this group.
• Closing Process Group: When it is time to officially close a project (or a phase, or even customer agreements), use the processes within this group.

It is easy to see why new learners confuse process groups with project phases, as there is some semantic overlap in the naming convention.

But, as a reader of this book, you should be aware that processes belonging to a group might be executed anywhere in the project life cycle. In particular, the Monitoring and Controlling Process Group is something the project manager will perform through most of the project life cycle.

Project management knowledge areas

There are 10 distinct specialization areas utilized by the project manager when managing projects. These are called Knowledge Areas. Each of these Knowledge Areas is also a collection of the same project processes that we have discussed so far.

Now, we will learn about the second way in which project management processes can be classified into Project Management Knowledge Areas:

• Project Integration Management: This knowledge area will be under the direct control of the project manager and deals with the co-ordination of all other processes utilized in a project. Other knowledge areas, which follow, can potentially be delegated to subject matter experts, such as a technical lead, quality lead, business analyst, or software architect. Another special point to note is that the integration management knowledge area has processes that are performed across the entire project life cycle.
• Project Scope Management: Ensuring that the project includes all the work required (and nothing else) to achieve the project objectives.
• Project Schedule Management: Concerned with the temporal aspects of the project such as sequencing activities and achieving time-related constraints.
• Project Cost Management: Deals with processes to ensure that the project does not exceed budgets. This includes estimating, budgeting, and control of costs.
• Project Quality Management: Using appropriate processes to achieve stakeholders' expectations of project quality.
• Project Resource Management: Resources include people, machinery, and materials (consumable or otherwise). Often, third-party vendors may be involved, or your own project may be part of a much larger project. In all cases, making sure resources are utilized optimally and on time is covered in this knowledge area.
• Project Communications Management: Project information should be periodically disseminated to participants in a project. A good project manager should understand the distinction between raw project data, information, and actionable knowledge.
• Project Risk Management: The skill of a project manager is in mitigating risks before they materialize – and if risks do materialize, designing contingency plans for them. All risk-related activities, including identification, analysis, response planning, and implementation, belong to this knowledge area.
• Project Procurement Management: Your project will often need products or services from outside your own sphere of control and you will be required to procure them. Procurement processes are within this area.
• Project Stakeholder Management: Stakeholders are those people, groups, or organizations that will be impacted by your project. So, a project manager uses appropriate processes to engage appropriate stakeholders, both during decision making and the execution of a project. These stakeholder-related processes belong here.

So far, we have understood project processes and learned about two different categorizations for them: Process Groups and Knowledge Areas. If you understand these systems, it will enable you to view your project processes from multiple perspectives.

Work breakdown structure (WBS) – a special mention

Running a project without a work breakdown structure is like going to a strange land without a road map – J. Phillips

In this section, we will examine a key project deliverable called Work Breakdown Structure. This is encapsulated in the project management processes that we have just familiarized ourselves with as the Create WBS process.

So, what is a WBS? The WBS is the breaking down of project work into smaller components to achieve the project scope.

The WBS is created during project initiation to manage the scope of the project. It is an application of the divide and conquer technique to break down the project scope into manageable components. After that, we use the WBS to create the project schedule (using Microsoft Project). Subsequently, the WBS is referred to, throughout the entire project life cycle, to monitor and control, and to close the project.

Despite its simplicity, WBS creation takes practice and skill to do correctly; and when done, will add significant benefit to the project. Due to the importance of WBS in executing schedules successfully, Chapter 6, Work Breakdown Structure – the Single Critical Factor, is dedicated to the practical aspects of creating a WBS.

Pitfall

Projects with a well-defined WBS might also fail, but a project with an incorrect WBS will seldom succeed. If your roadmap is incorrect, how will you reach your desired destination? In such a situation, course correction must happen, starting with the WBS.

How is a WBS different from the task/activity list? If someone asks about your project What are the project deliverables? the answer should be listed in your WBS.

Pitfall

The most common pitfall is to include the tasks in the WBS (instead of only deliverables and outcomes). Implementation details (tasks) belong to the task list and not in the WBS. The task list is, in fact, derived in a later stage, using the WBS as a foundation.

Why is a WBS important?

• The most important function of the WBS is Scope Management. A WBS helps in ensuring that the project includes all the work required (and nothing else) to achieve the project objectives.
• A WBS helps you to understand the work in the nascent stages of a project. It is also the critical step to proceed from Scope to Schedule.
• Changes are inevitable in projects and a WBS helps both in avoiding scope creep (uncontrolled changes to the scope) and as a reference baseline for scope change control.

Who should create the WBS?

The project manager has ownership of the WBS. But the actual bulk of the WBS content should be contributed by the following:

• Domain-specific experts
• Technical experts
• The team that is actually going to work on the project
• Business analysts

Reviews can be done by the following:

• Key identified stakeholders of the project
• Other project managers and teams that have done similar work

Why is a WBS so important in this book?

The WBS of your project should ideally be the input to create your schedule using Microsoft Project. So, it will really help to get familiar with this technique, through repeated practice.

Project management is a truly universal skill, required across all business domains, all geographies, and all the time.

The language of the project manager is the same across all fields: a software project manager can talk about schedule compression and a civil contractor will understand it perfectly, even though the rest of the other's professional terminology might sound like Greek to them.

But there are two misfortunes in this field:

• The first is that people who have been a part of a project at some point in their career will think that they can take on project management with no preparation whatsoever. It is also true that engineers will get promoted to project management roles by their boss, without verification of their aptitude or the downtime required to prepare for the role. Technically competent entrepreneurs start companies based on their passion, and then realize they also must manage organizational projects, which ends up being much more than the amount of work required for their product.
• The second misfortune is that, often, project managers who have had only academic training and certifications think they can take on a project beyond their capabilities.

Joel Spolsky, program manager on the Microsoft Excel team between 1991 and 1994, and cofounder of Stack Overflow, jokingly quipped in an essay about the existence of two mutually exclusive sets of genes: one for software development and another for management. The message is that the skills required for a technically oriented person and for a project manager are very different. And it is difficult for both to co-exist (but not impossible). There is more than a grain of truth in Joel's observation, no matter which business domain we look at.

It is all too common that the rock star performer of the team gets promoted to be the project manager. And they will find themselves doing something they have never been trained for in their lives, and often do not even have the aptitude for it.

The story is very similar when it gets to Microsoft Project.

The project manager fires up MS Project and because it resembles Excel a little, will innocently expect it to behave similarly. Very soon, they encounter the vast array of options and complexities of automatic scheduling, eventually giving up. Project management is very complex as it is; how do we use a software tool with a steep learning curve?

A few PMs might take a course or a book because their organization mandates the use of Microsoft Project. But then, they will not venture beyond creating a draft schedule at the beginning of the project. And there it will remain in the repository—uncared for, unloved, and never updated.

I have already heard a thousand different versions of this same story from my learners. And that is why this book aims to solve these specific challenges. If you complete the book while practicing all the hands-on examples simultaneously, then you will not be intimidated by Microsoft Project and your schedule will be a living document because it will reflect the true state of your project. Moreover, your boss (and their boss) will love your reports (which you can pull at the drop of a hat).

The Iron Triangle (Triple Constraint of Project Management)

Every project in real life is bound by constraints. If there was unlimited money or unlimited time, would there be any real challenge in project management?

You will have already heard of the famous Iron Triangle (or Triple Constraint) of Project Management:

Figure 1.3 – The famous Iron Triangle of Project Management (also known as the Triple Constraint)

The story is that, if your customer asks for good, fast, and cheap, you say, choose any two. The third parameter is your room for negotiation.

This concept is grounded on common sense and its origins are probably lost in the sands of time. And you will find multiple interpretations of it, each with a slight variation. But the gist is that any single vertex of this triangle cannot move without also impacting the other two.

Say you were building a house for a project. After all the planning, you start the project. Your significant other and your children now remember that they always wanted a swimming pool and you haven't factored it into your plan. At this stage, you will know that the additional scope means an additional cost and a few extra weeks, right? Moreover, if you don't have the luxury of extra budget or time, the quality of your project will decrease. This is what the Iron Triangle is all about.

And even this Triple Constraint model itself has a constraint. There are limits to which you can stretch this model, after which it breaks.

In his legendary book on software engineering and project management, The Mythical Man-Month, author Fred Brooks expounded that adding manpower to a late software project makes it even more late. This was written way back in 1975, and with the exponential expansion of software complexity and usage everywhere, the book's message rings even truer today.

The reason for this is that given that a project is already under pressure, adding more people to the team leads to added communications, additional requirements in the design interfaces, more training to get team members familiar with the project (requiring key team members to conduct knowledge transfer meetings), and so on. This will continue to the point when the project gets even more delayed than it already is.

How MS Project helps with the Triple Constraint

Microsoft Project's powerful automatic scheduling feature makes it a breeze to calculate the impact of additional scope on a project. Moreover, Project also provides some resource costing features that can be layered on top of your scheduling. We will see all these features in action throughout most of the book.

There are, of course, caveats: the additional scope should be well defined enough to be added to the schedule for Project's magic to work.

Microsoft Project and the mythical man-month

The mythical man-month predicts the drop in productivity caused by adding additional resources to a project. This unexpected reduction in productivity will be industry specific and largely depends upon the circumstances of the project. It is also very difficult to objectively quantify this productivity drop due to the unique nature of projects.

While it is possible to simulate such an effect using MS Project (by decreasing the resource units assigned to a task), it is very rarely practiced in real life. In the words attributed to the same author, Fred Books, everybody quotes it, some people read it, and a few people go by it, referring to the mythical man-month.

The elephant in the room (failure rates)

Despite the collective wisdom of millennia in project management, all studies show that the failure rates of projects are appalling. What constitutes a failure is generally acknowledged as overrun schedules and budgets, the unacceptable quality of the project result, or ultimately, the desired business objectives not being met.

While the inherently unique nature of projects builds a certain amount of risk into projects, it is also true that certain patterns can be observed from failed projects. We can immediately learn the following points from them:

• A higher complexity, size, and duration leads to failed projects
• Unrealistic schedules lead to real failures
• Not investing in baseline and variance analysis can be detrimental to project health
• Not tracking costs can sink the project ship

Winning – but at what cost (burnout rates)?

Poorly managed projects will cause teams to burn out. We have all heard of project managers leading teams into toxic work schedules, with no downtime to meet the unending Death March of projects.

Burnout, a word coined in 1974 by eminent psychologist Herbert Freudenberger, refers to the mental and physical breakdown of individuals caused by work-related stress. Unrealistic project schedules with relentless work hours, Kafkaesque expectations, extreme market conditions, the apathy of management, and any number of other factors, often simultaneous, can cause burnout.

And also, the world has tended to hero-worship the notion of project managers who pull off incredible goals. Steve Jobs, the charismatic cofounder of Apple, created what was half-jokingly referred to as the reality distortion field across the software industry. Jobs would use his personal charisma, hype, fear, or any other tools at his disposal to convince teams that anything he said was possible, especially fantastic project timelines.

This discussion would not be complete without mentioning the state of today's multi-billion-dollar video game industry. This industry, perceived by newcomers as fun, modern, and happening, has inordinately high burnout rates. Project schedules are perpetually in crunch mode. There is high churn in teams, which means that burned-out developers leave the company and brand-new workers are recruited into the company. Inexperienced developers, mostly fresh from college, are recruited for their ability to work long hours until burnout. Then they are churned out to make way for a fresh set of developers.

Project managers, like you and me, are at the frontline of the battle against burnout. Often the first impact on the team is on the PM themselves. The fight against burnout in all its forms should also begin with us. Today, there is a wealth of information to identify, prevent, and recover from burnout issues.

Where does Microsoft Project figure in the fight against burnout?

When a resource is allocated more work than they can handle in a standard workweek, it is called overallocation. Repeated overallocation over a lengthy duration is the first and foremost cause of worker burnout. This is not the same as the occasional crunch time that every real project faces – often during customer demos, or the final launch.

A project is stellar in identifying overallocation, and this is also recognized as the number one bane while creating your schedule. This book will cover overallocation with the highest priority, and we will discuss 10 different resolution techniques throughout the book.

Now, that we have had a tour of the vast landscape of project management, let's understand what Microsoft Project is really about. Of course, it is a software application to manage projects, owned by Microsoft, but it has a rich heritage and it will do you good to understand a bit more about it.

Microsoft Project, despite its modern, slick, and shiny interface, dates to the early 1980s, originally created by PC enthusiast Ron Bredehoeft and written for the DOS operating system. Microsoft purchased the software in 1985 and continued to release a few versions in DOS. The first Windows version of Project was released in 1990.

Three decades later, Microsoft Project is one part of a comprehensive enterprise-level management offering across project, program, and portfolio management. It encompasses desktop, web access, and server-based delivery.

At the core of Microsoft Project is a powerful scheduling engine. This engine is programmed to run according to some simple rules, concepts, and algorithms, all of which have their origins in the same project management theory that you have just learned about.

What does this mean for you? First, in software engineering terms, the application is robust. The team responsible for Project has had many decades to iron out all the chinks in the software already.

Second, millions of project managers have already created millions of schedules with the application in every imaginable business domain. Microsoft continues to collect feedback and input from expert PMs across a wide spectrum of business domains. This means that the algorithms have been tweaked and fine-tuned to work predictably for you.

Finally, you must understand that, even with all these big usage numbers, if you understand the simple precepts upon which Project is constructed, then Project becomes a powerful ally in your battle against scope creep, death marches, and burnout.

The Critical Path Method (CPM)

Microsoft Project uses the Critical Path Method for scheduling projects. Please pay special attention to this section as it is the foundation of the workings of Microsoft Project.

The CPM is a widely popular technique among project managers for sequencing activities (tasks) in a schedule. This special technique is embedded within MS Project as an algorithm. And the reason that I write tasks every time activities are mentioned is because "tasks" is the equivalent terminology in MS Project.

The technique involves, as a starting point, the following:

1. Breaking the project into a list of activities: This is based upon the WBS method that we discussed earlier in this section.
2. Estimating the duration (the time taken for the completion) of each activity: Estimates are usually provided by the people who will do the work, and then they can be verified by subject matter experts.
3. Identifying the logical dependencies between the activities: Most activities in a project will have the domain- or project-specific constraints decide the order in which they must be executed, for example:
   • In software development, development has to occur before the product can be tested, and internal testing must occur before customer testing.
   • A professional painter will prepare their canvas before painting it.
   • In civil engineering, the excavation of the foundation will be executed in the early stages of the project rather than later.
4. Identifying key events (milestones) and deliverable end points: By making use of these configurations, the CPM technique will calculate the longest path of activities to the end points of your schedule.

The diagram that follows shows a visual representation of the CPM. The whole figure represents a project schedule. The boxes represent tasks (or activities), along with the time it takes to execute them (DURATION). The arrows represent the sequence of execution of tasks via dependencies. Now notice the special small arrows in red , consecutively between the 5 boxes – they represent the critical path:

Figure 1.4 – Critical path represented by an activity-on-node diagram

Source: Reproduced without alteration from https://en.wikipedia.org/wiki/File:SimpleAONwDrag3.png under the Creative Commons Attribution-Share Alike 3.0 Unported license.

The advantage of this technique is that it will identify the following for you:

• The Critical activities of your schedule: A delay in any of these activities will result in the delay of the entire project. This path is the shortest time to complete the project and must be guarded carefully by the project manager. Any delay with any activity along this path will result in a delay for the entire project. It is often the longest path but not necessarily.
• The Float of your activities: This is the amount of delay that an activity can accommodate without delaying the entire project. It is often called Slack in project terminology. You may also surmise that activities on the critical path will have no slack.

  Tip

  If you are not already familiar with this technique of scheduling, it will be prudent to invest a few hours in self-learning this topic. This will give you an extra edge when tackling MS Project. You will be fine for the purposes of this book, even if you can't read it right away.

While the CPM technique is used algorithmically by Project, the visual representation of your schedule is predominantly represented by a Gantt chart.

Gantt charts

A Gantt chart is a special type of bar chart that visually represents a project schedule. Today, it is the de facto way of picturing schedules in software applications, in standards documents, official publications, and even informally on whiteboards and anywhere else you can imagine.

Gantt charts are named after Henry Gantt who first designed them in their current modern form around a century ago, circa 1910. Even though earlier designs were known and in use, Gantt's design revolutionized schedule representation and was promptly put to use in World War I by the United States Army. Here is a sample Gantt chart:

Figure 1.5 – Gantt chart

Image source: https://commons.wikimedia.org/wiki/File:GanttChartAnatomy.svg.

This work has been released into the public domain by its author.

Microsoft Project uses Gantt charts as the default representation, so if you are not already familiar with Gantt charts, this is the right time to do so. Project also has other special representations of the schedule (notably the network diagram or PERT diagram) to use for special and occasional analysis.

When to use MS Project (otherwise known as the law of the hammer)

When all you have is a hammer, every problem looks like a nail is a quote often attributed to Abraham Maslow, a renowned American psychologist. This quote refers to a tendency of over reliance on a familiar known tool or technique.

Microsoft Project is suitable for managing single projects of small to medium scale. Scale implies scope, project complexity, and the size of the team. The number of projects executed in the business world of this category, that is, of small to medium scale, far exceeds any other type.

How a particular organization categorizes, say, a small - or medium - sized project will vary as regards the obvious parameters. However, a rough rule of thumb would be to use Microsoft Project for projects sized between 10 and 200 person months of work.

When not to use MS Project

If you are looking at tiny projects—say with 1-2 resources and fewer than 10 person months of work—then you might consider simpler tools, because Project might be overkill. Excel is very popular, and Microsoft Planner is another lesser known tool. There are also many open source tools you might consider for tiny projects.

At the other end of the spectrum, if you want to manage a portfolio of multiple projects simultaneously across your enterprise—including managing resources shared across projects—then Microsoft Project is just inadequate. You might consider other offerings from Microsoft, such as Project Online/Project Server as a solution.

Tip

There is a 1980s-style feature called (perhaps loftily) Master Project, which allows you to merge multiple projects. But it has several pitfalls when used in today's business requirements and working styles. This feature will not be discussed in this book due to its shaky design. Microsoft probably retains this feature to appease organizations that have not yet made the Enterprise leap.

The Pareto principle states that for many events, roughly 80% of the effects come from 20% of the causes. In the case of learning Project, it is true that you will use about 20% of the features 80% of the time. These common features will be taught very early in the book.

Mapping to process groups and the project life cycle

Earlier in this chapter, you saw how process groups and the project life cycle are effective ways to organize your project management knowledge.

This book will use the same foundation, making it easy for you to use Microsoft Project as follows:

• Exactly how you need it in your job
• Mapped to the same PM process that you will execute

It is important that you practice all the hands-on assignments and exercises in this book. You can post solutions on my website, www.learngood.in (and look at other reader's solutions also).

Truly domain agnostic

Microsoft Project is domain agnostic; that is, literally any business domain can use it. In the same way, this book is also domain agnostic. The examples used in this book are from as varied business scenarios as possible to relate to a large and varied audience of project practitioners.

How to read the book (end to end reading versus pinpoint references)

Here are a few methods to help you to read and understand this book better:

• First time reading the book: Read the book end to end and your journey will be from simple to complex topics. After the very next chapter, you will be able to create simple but complete project schedules that can be utilized at work immediately.
• Pinpoint references: As a reference guide, you can jump to sections of this book that correspond to the stage your project is at or to the process group that you are executing in your own real-life project.
• As a textbook: Several colleges offer project management as a higher education course and strategically match it with Microsoft Project. This book will be a good match as a textbook as it maps to project management concepts.

In this chapter, we have seen how the global practice of professional project management has evolved and crystallized over the ages into global standards such as the PMBOK. We have gone over the basic framework of definitions and concepts that will enable us to navigate the rest of this book. Microsoft Project is a powerful tool that draws upon the same theory, techniques, and best practices of project management knowledge. At its heart is a powerful scheduling engine that works on the Critical Path method. We have also touched upon other essentials, such as the Iron Triangle, WBS, and Gantt charts. There is a sweet spot to which Project is best suited and it is not ideal for every type of project management.

Armed with this foundational knowledge, we are now ready to take on MS Project. In the next chapter, you will quickly get familiar with Project's user interface, so that the long arrays of buttons and features will not intimidate you in the future. We will also create a simple but functional project schedule! I look forward to meeting you in the next chapter.