Baseline – Godinterest

February 8, 2016July 1, 2022

How To Deliver On The Promise of MegaProjects

Due to the large scale and outlook attached to them, mega-projects have a large opportunity for failure. Typically, the failure begins at the outset of the project, whether that be due to poor justification for the project, misalignment among stakeholders, insufficient planning, or inability to find and use appropriate capabilities.

Underestimated costs and overestimated benefits often offset the baseline for assessing overall project performance. This is why it is important for organizations to first establish social and economic priorities before even considering what projects will answer their needs. Once social and economic priorities are established, only then can a project be considered. Selecting projects must be fact-based and transparent in order to ensure accountability with stakeholders and the public.

Successful Megaprojects Must Have Robust Risk-analysis or Risk-management Protocols

It’s also important to maintain adequate controls. Successful megaprojects must have robust risk-analysis or risk-management protocols and provide timely reports on progress relative to budgets and deadlines. Typically, progress is measured on the basis of cash flow, which is less than ideal as data could be out of date and payments to contractors do not correlate construction progress. Instead, project managers should deliver real-time data to measure activity in the field. For example, cubic meters of concrete poured relative to work plans and budgets.

Overall, improving project performance requires better planning and preparation in three areas: doing engineering and risk analysis before construction, streamlining permitting and land acquisition, and building a project team with the appropriate mix of abilities.

Project developers and sponsors should put more focus into pre-planning such as engineering and risk analysis before the construction phase. Unfortunately, most organizations and sponsors are reluctant to spend a significant amount of money on early-stage planning because they often lack the necessary funds, they are eager to break ground and they worry the design will be modified after construction is underway, making up-front designs pointless.

However, it’s proven that if developers spend three to five percent of capital cost on early-stage engineering and design, results are far better in terms of delivering the project on-time and on-budget. This is because through the design process, challenges will be addressed and resolved before they occur during the construction phase, saving both time and money.

It’s not unusual for permits and approvals to take longer than the building of a megaproject. However, if developers look to streamline permitting and land acquisition, that would significantly improve project performance. Best practices in issuing permits involve prioritizing projects, defining clear roles and responsibilities and establishing deadlines.

In England and Wales, developers applied these approaches to cut the time needed to approve power-industry infrastructure from 12 months to only nine months. On average, timelines for approval spanned four years throughout the rest of Europe. Likewise, the state of Virginia’s plan to widen Interstate 495 in 2012 was able to cut costs and save hundreds of homes thanks to land acquisition planning by a private design company.

Investors and Owners Must Take an Active Role in Creating the Project Team

When it’s all said and done, projects cannot deliver the best possible return on investment without a well-resourced and qualified network of project managers, advisers and controllers. Investors and owners must take an active role in creating the project team.

It’s not enough to have a vague overview of what the project might look like in the end. Instead, it’s necessary to review risks and costs and draft a detailed, practical approach to tackle various issues. An experienced project manager cannot do it all alone. The project team must include individuals with the appropriate skills, such as legal and technical expertise, contract management, project reporting, stakeholder management, and government and community relations among others.

Failure to Properly Plan for These Projects Could Have a Negative Impact on Society

While mega-projects are important in filling economic and social needs, failure to properly plan for these projects could have a negative impact on society. Take Centro Financiero Confinanzas (Venezuela), the eighth tallest building in Latin America at 45 stories, located in the financial district of Venezuela’s capital, Caracas for example.

To those unaware of its history, the Centro Financiero Confinanzas is actually home to over 700 families, a “vertical slum” that is a truly fascinating example of reappropriation of space in an urban environment. An ironic symbol of financial failure that was intended to represent the unstoppable march of Venezuela’s booming economy.

It’s much more than an unbuilt building, bridge or tunnel, failed mega-projects are a blow to the economic growth and social improvements of communities around the world.

November 21, 2015July 1, 2022

The Good, the Bad and the Ugly of Requirements Management

The Good, the Bad and the Ugly of Agile Methodologies

Most project managers know the importance of requirements management. Without a solid foundation and grounding in the subject, requirements management quickly turns towards the complex and difficult side.

Why Manage Requirements?

In the final analysis, all projects are completely driven by requirements. Requirements are usually not cast in stone. Stakeholders gather insights and more knowledge of their true needs with time. This means that they can change their minds about requirements, no matter how late in the game. Requirements should therefore be managed proactively in anticipation of change.

However, if requirement definitions are not set up properly in the first place, expect that the quality of delivery will suffer, along with more schedule delays than imagined, and a big drain on the budget.

Broad project requirements help to establish a baseline for objectives. Subsequent change requests would thus require approval by the right authority; a change control board is usually set up to investigate and approve changes to requirements. The objective of baselining is not to prevent or discourage changes, but to ensure that approved changes are relevant and deserve the priorities assigned to them.

The simplest way for project managers to reduce the probability of missing critical requirements is to hold requirements review sessions to ensure that stakeholders understand the requirements and that any ambiguities, inconsistencies and omissions are identified and addressed to facilitate requirements approval or sign-off.

However, when inaccurate requirements are in play, team members end up reworking those activities multiple times. The only sensible course of action is to deliver requirements up front in an accurate manner. That way team members will be able to immediately identify any missing components early in the project lifecycle.

It’s vitally important to employ tools designed to assess requirement quality at the beginning of the project. These tools will help to identify any requirements that are vague or missing early enough to improve the changes of success for the project. Even simple tools like guidelines and checklists can solve major problems later on. You may also consider automated tools, depending on your level of technical expertise.

The Good, the Bad and the Ugly of Requirements Management

Good Requirements

Requirements that meet the “good” standard are ones that anyone can easily evaluate to quickly and clearly determine that all the needs have been accurately met by the project.

The common criteria used by project teams to properly evaluate requirements is as follows:

Verifiable: Ensure that all deliverables are able to be evaluated to ensure they have met all necessary requirements. Verification techniques such as modelling, analysis, review by experts, simulations, and demonstrations or testing.

Testable: Requirements are able to be assessed using the most basic of all criteria. This includes quantitative measurement like “pass or fail.”

Traceable: Requirements should be tagged to specific sources. Examples are compliance requirements, best practices, industry standards, and use cases.

Clarity: All statements should be presented in unambiguous ways so the cannot be interpreted differently by different team members.

Bad Requirements

Bad requirements are marked by their incompleteness and lack of clarity. They are hard to understand and implement. They generally possess these characteristics:

Inconsistency: Without clarity, you’ll find requirements that are in conflict with other requirements! This is very frustrating because there’s no way that either one will ever be satisfied.

Non-valid: These are requirements that team members simply cannot understand. They will never be able to accurately assess or approve non-valid requirements.

Non-ranked: These requirements have not been correctly prioritised. Without proper ranking, it’s difficult for team members to be able to assess them properly.

The risk to the project not meeting the clients expectations is not something that will ever be entirely removed. However, having a specific criteria upon which to benchmark a project is a great way to reduce this risk.

Risks fall into two main categories. Systemic risk is inherent to the nature of the work and cannot be avoided. The non-systemic risk is a bit different and relates from the activities in the project itself. One of the greatest of all non-systemic risks is that of bad requirements management.

Teams that wish to reduce the risk of the project not meeting the clients expectations substantially are best served by establishing specific requirements in the initial stages. Common goals like being “on time and on budget” while maintaining a high level of quality will require dedication from teams members who have eliminated as much non-systemic risk as possible.

When you’re next involved in a project where requirements come up in a discussion, always pay careful attention to the good, the bad, and the ugly that could result without proper due care and attention.

October 15, 2015July 1, 2022

Project Manager or Scapegoat?

Big Project Failures Claim Their Victims in Spectacular Fashion

You’ve just been assigned a high visibility failing project and you’re working round-the-clock to get the work to the client on time, despite the fact that the job bears barely any resemblance to the project you initially discussed. The scope keeps creeping, the risk and issue alerts are coming in thick and fast, the project is already two months past the original deadline, the clients are getting antsy even though they’re yet to provide you with various key pieces of information in order to baseline the project. Is this your chance to shine and showcase your skills?

If You Don’t Know Where You’re Going, You Will Probably End up Somewhere Else – Laurence J. Peter

If you manage to turn the project around and the project is successful, you will attract many fathers. However, if the project fails, you will probibly be offered up as the sacrificial lamb (scapegoat), there is absolutely no way around it. A high percentage of projects fail to deliver useful results, that’s a fact.

Project managers are regularly blamed for schedule delays and cost overruns for projects they inherit by no fault of there own, however, in most cases, the fault for such issues rarely lies with just one person.

Sufficient data has been gathered to indicate that blockers such as unsupportive management, senior sponsorship or low resource availability are as much to blame for project failure as ineffective stakeholder management or poor communication.

Capture all decisions

The only way to protect yourself is to ensure that you capture all decisions made in the project. In most cases many of these decisions will have been made by people above you. While you can influence decisions made by people under you. Get into the habit of building a dashboard early in the project and updating it each week with actuals. Also consider using a standard repeatable technique to analyse the health of your project.

Constrained resources

If you are in a project where resources are constrained, clearly outline the resources that you require to deliver the project in terms of time, scope, budget, risk and quality. If resources are pulled from your project, clearly articulate the affect of that in delivery terms and measure that to time delayed or cost added.

Risk and issues register

Operate a strong risk and issue register, ensure it is both visible and assessable so your team can actively participate in updating it.

Stop the project

Always remember, cancelling the project is not always a failure. There can be many reasons why the project may no longer be desirable now. If you have done your job well, you can be really successful by ensuring a project does not continue to meander along, wasting time and money when there is no possibility of completing the project.

Organisational change management

Unfortunately, the same can’t be said when there are organisation change management issues. While there are a few project managers who feel their jurisdiction ends at the triple constraint, most now understand the need to achieve the expected benefits from their projects.

So when is it fair to blame a project manager for poor implementation of a project’s deliverables, this is assuming that they were employed at the beginning of the project?

If they didn’t perform good stakeholder analysis during the project initiation stage as well as at regular intervals.
If they turned a blind eye and deaf ear to factors that could impact value achievement
If they didn’t insist on a clear communication strategy and progressive information sharing with relevant stakeholder groups.
If they didn’t engage influencers from key stakeholder groups throughout the project lifecycle.
If the organisation management deliverables were not built into the project’s scope definition and work breakdown structure.

Assuming the project manager was appointed at the start of the project and had undertaken all of the above, what are invalid reasons to blame the project manager if the project failed?

A lack of timely resource availability or commitment by the organisation
Directives to the project manager to not engage certain stakeholder communities
Ignorance by senior sponsors to management risks raised by the project team
A management decision that is too bitter a pill to swallow in spite of how much it has been sugar coated

Have any comments or stories that could help to expand this article?