project management “triangle” of scope, time, and cost has been informing
projects ever since the first team member was hired to accomplish a job. In the
basic setup of a triple constraint, one of three elements (or possibly more)
can constrain a project. The elements are budget/cost, time/schedule, and
scope. If a change is posed to any one of these elements, something else must change.
WHAT IS THE TRIPLE CONSTRAINT
TRIANGLE IN PROJECT MANAGEMENT?
In the modern corporate landscape, a project is
typically “bound” or constrained by three elements, which may be expressed in
different ways. The triple constraint theory, also called the Iron Triangle in
project management, defines the three elements (and their variations) as
While the names of the three elements of the
triangle may change, they all measure essentially the same thing: a fixed
budget, a fixed schedule or timeline, and a fixed set of expectations or
The triangle comes into play when something affects
one of its “legs.” If that happens, you may need to adjust one or both of the
other elements to accommodate the change. For example, if a client suddenly
shortens a time frame, then a project will likely need more resources, or
perhaps a scope reduction.
In another case, a company may have two competing
projects, but not enough staff to fully support both. A project manager may
then need to move employees from the first project to the second, which affects
either the scope of the first project, or the timeline, or both. In other
words, a project manager can make these changes, but something’s got to give.
The concept of “quality” is sometimes introduced as
another factor in the project constraint triangle, or as a fourth “leg” in what
would be a project diamond. However, there are varying views on this, as
quality is subjective. Does the quality of a less-in depth web page suffer, or
can it still be a high-quality page with reduced scope? These are questions a
project manager must always consider and keep in mind during conversations with
stakeholders and clients.
A project manager is the person responsible for
accomplishing the project objectives. Key project management responsibilities
defining and communicating project objectives that are
clear, useful and attainable
procuring the project requirements like workforce, required
information, various agreements and material or technology needed to accomplish
managing the constraints of the project management triangle,
which are cost, time, scope and quality
A project manager is a client representative and has to
determine and implement the exact needs of the client, based on knowledge of
the organization they are representing. An expertise is required in the domain
the Project Managers are working to efficiently handle all the aspects of the
project. The ability to adapt to the various internal procedures of the client
and to form close links with the nominated representatives, is essential in
ensuring that the key issues of cost, time, quality and above all, client
satisfaction, can be realized.
IT Project Manager
IT Project Management generally falls into two categories,
namely Software (Development) Project Manager and Infrastructure Project
Software Project Manager
A Software Project Manager has many of the same skills as
their counterparts in other industries. Beyond the skills normally associated
with traditional project management in industries such as construction and
manufacturing, a software project manager will typically have an extensive
background in software development. Many software project managers hold a
degree in Computer Science, Information Technology, Management of Information
Systems or another related field.
In traditional project management a heavyweight, predictive
methodology such as the waterfall model is often employed, but software project
managers must also be skilled in more lightweight, adaptive methodologies such
as DSDM, Scrum and XP. These project management methodologies are based on the
uncertainty of developing a new software system and advocate smaller,
incremental development cycles. These incremental or iterative cycles are time
boxed (constrained to a known period of time, typically from one to four weeks)
and produce a working subset of the entire system deliverable at the end of
each iteration. The increasing adoption of lightweight approaches is due
largely to the fact that software requirements are very susceptible to change,
and it is extremely difficult to illuminate all the potential requirements in a
single project phase before the software development commences.
The software project manager is also expected to be familiar
with the Software Development Life Cycle (SDLC). This may require in depth
knowledge of requirements solicitation, application development, logical and
physical database design and networking. This knowledge is typically the result
of the aforementioned education and experience. There is not a widely accepted
certification for software project managers, but many will hold the Project
Management Professional (PMP) designation offered by the Project Management
Institute, PRINCE2 or an advanced degree in project management, such as a MSPM
or other graduate degree in technology management.
IT Infrastructure Project Management
An infrastructure IT PM is concerned with the nuts and bolts
of the IT department, including computers, servers, storage, networking, and
such aspects of them as backup, business continuity, upgrades, replacement, and
growth. Often, a secondary data center will be constructed in a remote location
to help protect the business from outages caused by natural disaster or
weather. Recently, cyber security has become a significant growth area within
IT infrastructure management.
The infrastructure PM usually has an undergraduate degree in
engineering or computer science, with a master’s degree in project management
required for senior level positions. Along with the formal education, most
senior level PMs are certified, by the Project Management Institute, as a
Project Management Professional. PMI also has several additional certification
options, but PMP is by far the most popular.
Infrastructure PMs are responsible for managing projects
that have budgets from a few thousand dollars up to many millions of dollars.
They must understand the business and the business goals of the sponsor and the
capabilities of the technology in order to reach the desired goals of the
project. The most difficult part of the infrastructure PM’s job may be this
translation of business needs / wants into technical specifications.
Oftentimes, business analysts are engaged to help with this requirement. The
team size of a large infrastructure project may run into several hundred
engineers and technicians, many of whom have strong personalities and require
strong leadership if the project goals are to be met.
Due to the high operations expense of maintaining a large
staff of highly skilled IT engineering talent, many organizations outsource
their infrastructure implementations and upgrades to third party companies.
Many of these companies have strong project management organizations with the
ability to not only manage their clients projects, but to also generate high
quality revenue at the same time.
The Project Manager is accountable for ensuring that
everyone on the team knows and executes his or her role, feels empowered and
supported in the role, knows the roles of the other team members and acts upon
the belief that those roles will be performed. The specific responsibilities
of the Project Manager may vary depending on the industry, the company size,
the company maturity, and the company culture. However, there are some
responsibilities that are common to all Project Managers, noting:
a freelance project manager, I was involved in many projects. A lot of teams
are using the term Agile but are working in an “Inter-Sprint Waterfall” or
“Intra-Sprint Waterfall” process. In this article, I will explain the
difference between “Waterfall”, “Inter-Sprint Waterfall”, “Intra-Sprint
Waterfall” and “Agile”
What is Waterfall?
introduced by Dr. Winston W. Royce in a paper published in 1970, the waterfall
model emphasizes that a logical progression of steps be taken throughout the
software development life cycle (SDLC), much like the cascading steps down an
incremental waterfall. While the popularity of the waterfall model has waned
over recent years in favor of more agile methodologies, the logical nature of
the sequential process used in the waterfall method cannot be denied, and it
remains a common design process.
below the 6 stages of Waterfall.
Requirements: During this initial phase, the
potential requirements of the application are methodically analyzed and written
down in a specification document that serves as the basis for all future
development. The result is typically a requirements document that defines what
the application should do, but not how it should do it.
Analysis: During this second stage, the
system is analyzed in order to properly generate the models and business logic
that will be used in the application.
Design: This stage largely covers technical
design requirements, such as programming language, data layers, services, etc.
A design specification will typically be created that outlines how exactly the
business logic covered in the analysis will be technically implemented.
Coding: The actual source code is finally
written in this fourth stage, implementing all models, business logic, and
service integrations that were specified in the prior stages.
Testing: This stage, QA, beta testers, and
all other testers systematically discover and report issues within the
application that need to be resolved. It is not uncommon for this phase to
cause a “necessary repeat” of the previous coding phase, in order for revealed
bugs to be properly squashed.
Operations: Finally, the application is ready
for deployment to a live environment. The operations stage entails not just the
deployment of the application, but also subsequent support and maintenance that
may be required to keep it functional and up-to-date.
overview of the Waterfall process:
What is Inter-Sprint waterfall?
An “Inter-Sprint Waterfall” looks like this: In one
sprint, the business product owner, probably a business analyst and visual
design team (UX/UI) are working on the “What” needs to be built. Since they are
working “Agile”, they adopt some agile process. Requirements will be documented
in user stories. The user stories are not treated like real user stories but
more like mini-specification documents (or longer). The mini-specs/user stories
are nearly conceivable about a given user story.
The whole sprint 0 is consumed to figure out and document
the user and technical requirements. Grooming sessions are conducted, visual
designs created, UX flows and style guides are created. A second sprint is
added to develop the new features. Several documents are handed over to the
programmers. Visual designs, spec documents, UX flows, etc. No programming can
start until all defined artifacts are delivered. The programmers take an
attitude of saying that they will build everything that is asked for. Some team
members are sometimes a little more agile and develop all mini-spec before a
user story is completed. Other team members think it is dangerous to work in an
The third sprint is used in some organizations for testing
purposes only. In the Inter-Sprint Waterfall method, the test team is working 1
sprint behind the programmers. Fortunately, most teams realize that developers
and testers need to work in the same iteration. They do not extend this to the
This leads to the process shown in this figure.
This figure shows a first iteration devoted to design. A
second iteration (possibly slightly overlapping with the first) is devoted to
development. And then a third iteration is devoted to testing. It might be your
organization’s first step toward becoming agile. But it’s not agile.
What is Intra-Sprint waterfall?
who used to work in an extensive waterfall development environment, and who are
new to agile, often think that a sprint is a mini waterfall. It is not!
“We tried Agile/Scrum but it
team tried an iterative waterfall development approach. Same mistakes as
described in the “Inter-Sprint Waterfall method” were made. User stories are
An “Intra-Sprint Waterfall” looks like this: In one
sprint, the business product owner, probably a business analyst, and the visual
design team (UX/UI) are working on the “What” needs to be built. Since they are
working “Agile”, they adopt some agile process. Requirements will be documented
in user stories. The user stories are not treated like user stories but more
like mini-specification documents (or longer). The mini-specs/user stories are
nearly conceivable about a given user story.
Once the requirements are done, the team will start
developing during the defined time box. If the development is finished, that
test team will do the validation within the same timebox.
approach might work if features are prioritized and time-boxed. A strong
definition of done and to not deliver features that are incomplete.
What is agile?
is a specific project management methodology, most often used by software
developers and engineers. This Agile project management methodology is a
time-boxed, iterative approach to software delivery that builds software
incrementally from the start of the project, instead of trying to deliver it
all at once near the end. Traditional project management techniques focus on
achieving identifiable milestones using complex scheduling tools like Gantt
charts. It works by breaking down projects into little bits of user
functionality called user stories, prioritizing them, and then continuously
delivering them in short two week cycles, called iterations.
Ideally, in an agile process, all types of work would
finish at the same time. Constant feedback from the end users is asked to help
developers and the product owner defining functionalities that would be
integrated into the succeeding builds. The teams are Cross-Functional teams and
work on interactions of a product over a time-boxed period. The work is
organized into a backlog that has been prioritized based on the feedback of the
clients’ needs. The backlog serves to constantly remind each team member that
the goal of each iteration is to produce a working product.
The team would finish analyzing the problem at the same
time they finished designing the solution to the problem, which would also be
the same time they finished coding and testing that solution. Multiple features
are analyzed, developed and tested by the cross-functional teams and are
time-boxed. At the end of the iteration, a demo is held. The client is able to
provide fast feedback. Based on the feedback, changes can be implemented and
moved into production.
management is not always the best choice for every industry, especially those
involving long-term, complex decision-making processes. Agile allows managers
and team members to make quick tweaks and adjustments. Problems caught before
they progress too far or affect other areas of a project save a great deal of
time and help businesses stay faithfully within budget.
The complete picture ‘Waterfall” vs “Inter-Sprint
Waterfall” vs “Intra-Sprint Waterfall” vs “Agile”
So what methodology would you use?
There is no need to say which methodology
is better. You can choose the one that is the best for your project.
Take as much advantage as possible of
what you know. Then you would take an iterative, trial-and-error-and-learn
approach to find the best methodology.
You have to be a bit of a renaissance person to be a successful project manager. You need skills and natural abilities that range from being a tactical problem solver to reading the nuances of human behavior. If you’re just getting started as a project management professional, then hat’s off to you! To help pave your way to a brilliant career, here are 11 tips for new project managers.Listen and engage. You can’t learn if you don’t listen, and this is a time to soak everything up. Pay attention to the landscape of your team; study your clients and customers; start to recognize the strengths of your teammates (an important skill for successful PMs). Then, take all that great listening, and engage with your team members and stakeholders in ways that matter to the project’s success. The more people you can get on your side from the beginning of the project—and your career—the more success you’ll have. Listening gives you material to use in building relationships.
Be a problem solver. Sometimes junior PMs (and senior ones) rush into the doing of a project before analyzing all the dependencies and identifying all the risks. See how much preemptive problem solving you can do up front to contribute to your team. And if you experience a project that goes awry in any way, put on your Private Investigator hat and find out the why-what-where-and-when of what caused the project to fail. The best lessons come from mistakes. But they’re only valuable lessons if you apply the learnings.
Be an effective team player. You want to both serve your team in your project’s best interest, and learn how to optimizing your team members’ expertise. Being a team player also means asking for help when you need it. You don’t want to be the person who waits too long to let others know there’s a problem brewing. Be a transparent problem-solver and let your team know the minute you spot trouble on the project. Be a pre-emptive thinker.
Know your project management tool. Whether you’re the one overseeing the project schedule, or you’re using collaborative project management software, make sure you know how to use the tool inside and out. Find ways to optimize the platform and encourage team members to participate fully, if applicable. If you think there’s a better way, take the lead to find a product that serves your needs better. Such initiative could win you points.
Know your customer. While it’s important to know who exactly you’re working for, it’s even better to know who your customers are as individuals and as an organization. Understand what your customer’s goals, vision and mission are; identify what they care about and how they like to communicate. Learn how they deal with change and project turmoil, or how they like to face conflict and solve problems—that kind of stuff. If you can react to your customers and clients in the most appropriate and meaningful way for them you could hear “promotion” before you know it.
Learn how to read people. AKA emotional intelligence, some people know how to read the mood of a room, but people skills can be learned. Learning about human behavior is (hopefully) a life-long process, but if you’re really good at it, or work really hard at developing your emotional IQ muscles, you’ll stand out among your peers in a big way.
Find a mentor. Mentorship is becoming a well-regarded and much-practiced path to career growth. There are many theories on what makes an appropriate mentor, but here are some options for mentor possibilities: co-workers, managers and former bosses, family members, teachers, friends, and a formal mentorship program. Or, in place of an official mentor, find someone whose working style you can model.
Enjoy taking on responsibility without full authority. One day you’ll be the person making all the big decisions—but don’t rush it. These are the golden days of opportunity, when you can take chances and learn in a forgiving environment without having to take the bit hit of responsibility. Savor it; your time will come.
Embrace change. Uncertainty is part of every project, so there will be many unexpected surprises in your project management career. You need to be flexible, adaptable and improvisational. Be the person who is ready for change and comes armed to the emergency meeting with strong solutions.
Get your Prince2 certification.Getting credentials can be an asset to any career. However, receiving your Prince2 has pros and cons. If you have the time, interest and company support it could be a great way to go.
Be kind, be honest, have a sense of humor. Being in charge doesn’t mean you have to take on a dictator’s personality. Treat people the way you’d like to be treated—with respect and as sense of humanity. After all, we’re all in this together.