INFRASTRUCTURE PROJECTS

“Of all the things I’ve done, the most vital is coordinating the talents of those who work for us and pointing them towards a certain goal”

-Walt Disney

Understanding The Waterfall Methodology:

For this book what we wanted to do was to provide a primer on the basics of Waterfall project management.  The basic idea for this is to really provide a framework for those of you wishing to enter the thrilling and challenging world of project management.

For more detailed discussion of both Waterfall and Agile project management methodologies, please refer to our book, The Agile Project Manager 2020, available at Amazon and other fine stores.

The Current Project Management Landscape:

What does a current project look like?  Well if you are like me, you have seen a lot of successful projects as well as some that completely collapsed.

Typically we see projects that are poorly planned and rushed into production, or the opposite of this where projects are over planned and stakeholders get frustrated and give up.

Software Development is expected to grow by 40% in the next five years.  The question is how exactly will projects be led, managed and coordinated.

This is our objective here to determine exactly what the best plan should be moving forward into the next decade.

Waterfall is so named because it follows a structured, linear process that involves a great deal of planning up front and a slow start.  One of its primary objectives is to cover and identify as many possible issues in the Initiating and Planning phases, such that the Execution becomes fairly straightforward.

Agile differs with that in that it allows for more changes, whereas Waterfall is mostly locked in once the Planning phase is completed.  This makes incorporating changes less dynamic.

It pains me to admit it, but this one is rather dull.  Not the writing, that is of course riveting, but the subject matter itself.

The Waterfall Methodology:

Project Management Process Groups:

An overview of the basic project management process groups

• INITIATING
• PLANNING
• EXECUTING
• CONTROLLING/MONITORING
• CLOSING

Let’s first discuss the Project Management knowledge areas, and then we will move in to discuss the specifics of each of the Project Management Processes in the Waterfall model

Project Management Knowledge Areas:

Within the process groups, many management types comprise the full management of a project.  PMBOK defines these specialized management skills as knowledge areas.  Each knowledge area is present in at least two of each of the process groups. 

Knowledge Areas:

Scope Management

Scope management revolves around defining the work that will and will not be included as part of the project.  Managing scope requires that you identify and document the requirements necessary to make the project a success.

We will discuss the multiple approaches to defining scope that can be taken when planning a project.  One of the key points of the book is that scope should be the most flexible area of any project.  When projects start, there are many situations in which the scope simply cannot be all defined at once.  Not because the Project Manager does not have the ability, but rather the stakeholders don’t yet know exactly what they want.

For this reason, we feel that scope management is one of the most important facets of any project and the one that should have the most latitude and flexibility during the project.

Cost Management:

During planning, the cost of project work is estimated.  These costs include materials, other resources and labor costs.  From these costs, a budget can be constructed and defined.

From here, as the work progresses, the status of the project is monitored and we compare the budget to the amount spent.

Time Management:

Typically when a project starts, the stakeholders provide a due date.  This due date is not necessarily a so-called “drop dead date” but rather say a quarterly target or some other customer-dictated date.

Sometimes there are fixed dates that simply must be met, say for example for federal tax compliance, before the end of a quarter for reporting purposes etc.  From this defined date, a project manager must put time management into practice.  This is defined by generating the project schedule.

 Tasks need to be defined and then must be estimated and scheduled.  Here is where certain project methodologies differ with their planning methods.  In traditional waterfall, these tasks are defined, estimated and scheduled in a linear, Gantt chart method and followed in a straightforward manner.

Agile project management involves different scheduling approaches, by which tasks are estimated by effort and then planned into two-week sprints as selected by the team.  We will discuss this in greater detail later, but this is how we see Agile as being more advantageous, as it enables the team to participate in the estimating and planning progress.

By being more involved, typically estimates are a great deal more accurate and the team members also feel more engaged in the process.

Once the project is underway, the Project Manager must monitor progress and take steps necessary to control the schedule. 

Human Resource Management:

As part of the planning process, once the tasks are estimated, the skills and roles are identified that will be required to complete said tasks.  This staffing plan is developed and then added to the project.

In our opinion, the Project Manager should be very involved in the selection of the team members and understand the abilities and strengths/weaknesses of each potential team member.

The Importance of Team:

There is one key point to make here, which we will elaborate on later in the book.  Next to stakeholder communication, we feel that engaging the team and creating a feeling of team unity is the most important responsibility of the Project Manager.

Few things are more motivating that belonging to a group that works together seamlessly towards the same goal.  This can be very difficult to do, but should be one of the areas in which Project Managers focus their time.

Be Part of the Team:

Now the balancing act that all Project Managers must face:  how can we lead the team while being a contributing part of it at the same time?  This is for those of you Project Managers who are not that technical, but may be managing a technical project.

One key piece of advice is to, at least, understand the technology enough to both speak to it and to understand what is being discussed.

I have worked with several Project Managers who were assigned very, very technical projects to manage.  One of my former colleagues, Mark, was so non-technical that he had difficulty simply accessing tools on which to record status reports.  This was ok for a while until he started managing complex software development projects for a key company initiative.

On this project, some of the developers on his team would snicker behind his back because they felt that they could tell him any type of technical B.S and he would not have a single clue that they were lying to him.  This lack of respect plagued the project and ultimately it was unsuccessful.

Project Managers need to become technically proficient at least enough to understand what is being said.  I remember my first infrastructure project when the architects were discussing the difference between Virtual Machines and physical servers and details such as this.

I felt completely uncomfortable, but performed my due diligence, did some research and then for the next meeting I was able to add some valuable comments or ,at least, comment on something without completely sounding stupid while doing it.

The key point here is that by not understanding the technology involved in the project it sends an unintentional message to the team either that the PM is too good to need to understand the technology or that he or she doesn’t care enough about it to learn to speak about it.  Obviously, either of these two perceptions is not positive.

Procurement Management/Sourcing:

This most often refers to a situation in which a purchase is needed such as a software system.  This can also refer to the process of obtaining outsourced or contract workers for the project if the in-house resources are deemed either unavailable or insufficient for the project at hand.

More often than not, this process will involve a separate department that helps to work with the vendors and take care of details such as the request for quotations, request for proposals and then the vendor evaluation process.

I have had several projects, however, where the Project Manager and the Stakeholders had the discretion and liberty to manage all of this themselves, and then would simply bring in the Sourcing department at the end to manage the paperwork and then legal to do the contract negotiations.

 Communication Management:

As we will continue to stress in this book, we feel that Communication is the key responsibility of a project manager.  This includes the communication with the project team, and equally important is the communication with the stakeholders and the project sponsor(s).

The Communication Plan is one key component of project communication, but we recommend that Project Managers develop a skill to have the flexibility to deviate from this plan based upon the personality types of the stakeholders on the specific project.

Once a communication plan is finalized, you may see that for some projects everyone is quite comfortable with the plan and that no issues arise.  Other projects seem to have that one stakeholder who needs more assurance, more frequent updates and that warm and fuzzy feeling that the project is proceeding as planned.

One of my key lessons learned in project management is that not everyone is an optimist.  I always firmly believed that unless I said anything to the contrary, people would know that the project was on schedule, everything was fine and there were no issues.

Well, quite the opposite is true.  Without constant reassurances and reminders, people start to get nervous, and unfortunately, tend to assume the worst unless they are constantly reassured and comforted.

You should always over-communicate as opposed to under communicate.  I am not sure why, but nothing creates more resentment and misunderstandings than failing to clearly communicate project status consistently and almost on a daily basis.

Quality Management:

Quality control represents measuring and recording the results of quality activities you can use to test your deliverables.  An aspect of quality assurance is ensuring that the quality of your project complies with the standards defined by your organization. 

Here is where some quality control mechanism could be applied to help eliminate consistent errors that are occurring across the enterprise.  We advise Six Sigma, details of which will be discussed later in this book

Risk Management:

What is a Risk?  A risk is defined as an event that has some probability of occurring in the future.  A risk need not be negative, but we typically don’t have to worry too much about positive risks, since a change to the positive won’t typically create problems.

We identify risk management with three processes although many claim it to be four.  These processes are identified as follows:

-Recognize risks and assess the probability of occurrence

-Differentiate between risks and issues.  Remember a Risk is defined as something that may occur, whereas an Issue is something that has happened.

-Develop Risk Responses

-Monitor and respond to Risks

THE WATERFALL FIVE PROJECT PHASES:

THE INITIATION PHASE:

The Initiation process group is the first of five PMBOK defined project process groups.  The initiation processes formalize the authorization to start a project.  Remember also that process groups can apply to both a new project and a new phase of an existing project.

Most projects I have worked on have not required this, but it can happen.

At the beginning of a project, the Initiation processes link the project’s business needs to the project.  Clear business goals and objectives are developed and tied to the rationale for the projects need.  Basic budget estimates are defined and the project team is identified.

The project scope is examined first in the initiation phase and key structural decisions are made about how the project will be planned and executed.

Project Initiation Stage Major Outputs

There are two major outputs in the project initiation stage:

• A Project Charter
• A Preliminary Project Scope Statement

Project Initiation will be consistent regardless of which Project Management methodology is chosen.    The execution might be different, but the steps leading up to this are all fairly consistent.

Initiation phases should involve asking the questions to determine what is being addressed by this project.

This analysis should be done even prior to the completion of the project charter.

Key Points in the Initiation Phase:

Problem Statement – What is the problem?

Project Objective – What is the purpose/objective of the project?

Project Scope -- What will the project do and not do

Success Criteria – This is likely the most important factor.   What makes the project successful?  This criterion should be defined by the business stakeholders and internal customers if there are any.  As we have learned from many past projects, what defines a successful project can vary from time to time. 

Problem Statement – problem statement should not state a solution but rather simply note the situation that exists and the opportunity for improvement

Project Goal – The goal statement is the opposite of the problem statement.  The Goal statement is the intended outcome of the project.

The goal statement should be phrased in a positive manner and describe the “To-Be” objectives of the project.  One way to think of the difference between the problem statements as just that, the Problem statement is the “as is” description of the current existing problem.

The goal statement is the envisioned perfection of the “to be” future vision, and that which hopefully this project will resolve.

Example Problem Statement:

Project Objectives:

The project objectives are explicitly designed objectives that flesh out the vague goals defined in the goal statement.

When these objectives have been accomplished, the goal is considered to be completed.

Whereas a goal statement should be fairly vague and not prescribe a necessary solution, the project objectives should be far more specific.

I feel that this acronym is somewhat overused (as are many in our business

TO LEARN MORE -- CLICK THE LINK BELOW TO ORDER THE AGILE PROJECT MANAGER 2020 AT AMAZON.COM TODAY