Category Archive :Project Management

The 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.


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 follows:

  1. Scope, time, budget
  2. Scope, schedule, cost
  3. Good, fast, cheap

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 deliverables.

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.

What is a Project manager?

A project manager is the person responsible for accomplishing the project objectives. Key project management responsibilities include

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 project objectives

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 Manager.

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.[3] 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:[4]

  • Developing the project plans
  • Managing the project stakeholders
  • Managing communication
  • Managing the project team
  • Managing the project risks
  • Managing the project schedule
  • Managing the project budget
  • Managing the project conflicts
  • Managing the project delivery

As 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?

First 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.

Find 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.

High-level 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 agile way.

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 whole team.

This leads to the process shown in this figure.

Inter-Sprint Waterfall

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?

People 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 didn’t work”.

The team tried an iterative waterfall development approach. Same mistakes as described in the “Inter-Sprint Waterfall method” were made. User stories are too complex.

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. 

Intra-Sprint Waterfall

This 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?

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.


Agile 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”

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.

Rob Gielen

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.