Skip to main content

Author: Paul Taplin

Effective Project Management Without Apps

If you want a really good project outcome, close down your PM apps and tools for a few days, and just reflect on the nature of the new project you’ve just been handed!

As with most things, successful projects start with well-considered preparation. Here are a few suggestions as to how you can give your project the best chance of success before you open any apps.

These suggestions are largely pitched at infrastructure and building projects, but most of the comments hold true for ICT and process improvement projects as well.

What is success for your project?

→ Establish clear agreed project objectives and measures.

What is “success” for your project? How will you know when you’ve got there? Have you agreed on the project objectives and risks/constraints with the project sponsor?

All successful projects, whether they are engineering and building projects, ICT development projects or less tangible social development projects, start with clear agreed objectives and performance measures. In fact, the more intangible or qualitative the desired outcomes, the greater the need for clear objectives and measures.

The objectives should be project specific so that they are achievable within your accountability, rather than corporate objectives over which you have limited influence. You may need to re-work the project objectives so that they adequately describe the desired project outcomes, and are measurable and achievable within your accountability.

How “carte blanche” is your delegation and accountability?

→ Seek the maximum level of delegation to communicate, and clarity on approval to commit.

How far does your delegation extend? What can you commit to without seeking approval? Have you actually obtained any meaningful written delegation?

Effective project management requires the PM to be able to interact and collaborate across the whole organisation, and hopefully across the broader external environment, without travelling up and down the organisation hierarchy each time you need to communicate with key players in the delivery chain.

The key point here is to maximise your delegation to communicate widely, and not necessarily to make momentous or fundamental decisions. The latter is managed within the project’s governance framework.

How effective is the project’s governance framework?

→ Assist the organisation to operate an effective project governance framework.

It’s important to remember that the PM’s role is to deliver the project successfully, and not to invent project content or make arbitrary scoping and specification decisions. Accountability and decisions regarding project funding, scope and specifications are the role of the organisation, communicated via a project governance framework to which project management activity should be ultimately accountable.

You may have to assist the project sponsor to develop an effective project governance framework, identifying the ultimate accountability chain, and the key corporate players who have organisational accountability for funding, scoping, legal support, communication and technical compliance.

Whilst the existence of a corporate steering committee or similar may sometimes appear to be a burden from the PM’s perspective, if the project starts to experience difficulties, especially with stakeholders, then the governance framework will be of immense value to keep the project on track.

How mature is your organisation with respect to project management?

→ Recognise the level of project management maturity in your organisation.

PM maturity (the ability and structure to support effective project management) within an organisation is a key success factor. Mature organisations provide effective policy and guidelines for project management, low barriers to cross-functional communication (the near absence of silos and fiefdoms), and a range of templates and support material. The organisational role and status of the PM is understood and accepted. Organisational relationships are clear, and the staff are at ease with the duality of functional and process accountabilities.

On some occasions, the organisation’s project management maturity will be less than desirable, and unfortunately, this is an area that the individual PM can do little about directly. The best you can do is to recognise any management shortfalls and create your own systems and templates as you require. You may then be able to lobby for the organisation to accept your systems corporately.

Where did this project come from?

→ Understand the genesis of your project, and its associated risks.

Take some time to consider and identify the genesis of this project. Was it born out of careful planning, or was it hatched as a knee-jerk reaction to a perceived threat? Does the project have demonstrable corporate and stakeholder support, or is support a bit tenuous and narrow?

How is your organisational life as a PM likely to fare over the project lifecycle? Have you been handed a poisoned chalice, or a great opportunity just waiting to be delivered?

It’s important to understand the genesis of the project so that you can position yourself and your team accordingly. A thorough understanding of these aspects should also lead to the generation of project risks associated with the project’s history and climate, so that any difficult issues can be identified in advance and managed effectively.

How much prior documentation exists?

→ Identify and acknowledge all previous project documentation.

The amount of prior documentation will depend on the point at which the PM was invited to commence. Mature organisations appoint their PM early in the project lifecycle, and the PM will be there to see the development of the project development plan and procurement plan. It is likely that the business case will already have been finalised.

Whatever your point of entry, it’s critical that relevant project documentation exists, and that this documentation embodies the intent and legitimacy of your project within the organisation. The PM may have to initiate action to ensure that this documentation is formally signed off and published. The PM should also ensure that any gaps or unqualified risks are identified, acknowledged and rectified prior to proceeding with the project.


Advertisement
[widget id=”custom_html-68″]

Are the project expectations realistic?

→ Understand the features and realism of the organisation’s project expectations.

The chances are that the business case that launched the project was developed and written by someone else. That someone else may have been an excellent business case writer, but they may also have carried forward some highly optimistic expectations for the project, including the budget and the benefits. Also, consider that often the business case author may not carry ultimate responsibility for project delivery.

There are several key factors that may lead to undue optimism. The first is standard optimism bias, which can understate the required budget and overstate benefits by at least 20%. The second factor is the human condition of being “eager to please”! Organisations or individuals that are eager to satisfy political or corporate expectations may trim off cost estimates, exaggerate benefits, and minimise risk contingencies in order the get the project over the line. The third factor is the preliminary state of the scope and design at the time of seeking approval for funds, meaning that the budget is based on a very thin concept design that would not normally be used for cost estimation. How thorough was the investigation and preparation for the project? Was the business case based on a thorough feasibility study, or was the feasibility planning skipped because of indications that the sponsor government or organisation wanted the project outcomes anyway?

Any unrealistic expectations or assumptions need to be highlighted and remedied before the project gets into its stride, otherwise, the PM will be continually perceived to be under-delivering.

What are the current expectations?

→ Ensure that project expectations and assumptions are contemporary.

If the project has been in gestation for a while the business case and any project planning material may not be current, and circumstances may have changed. The political or organisational climate may have moved on. The supplier market may have changed. Other projects or initiatives may have changed the risk profile of the project.

A brief review of the project documentation against the current landscape is valuable to give the PM confidence that the project is still viable. If there are any assumptions that don’t appear to hold up in the current climate, then this is the right time to flag them, and to seek modifications before the project builds up too much momentum.

Who are the key influencers and beneficiaries?

→ Stakeholder engagement planning is critical to project success.

Before getting too carried away with delivery planning, it’s worth reflecting on the nature of the key stakeholders. The stakeholders should be categorised in terms of key influencers (positive and negative), important technical support, passive communities and the ultimate beneficiaries.

With the rise of communications through social media, a relatively recent phenomenon is the impact of the “nimbys” – “not in my backyard” protesters. Major projects that deliver broad scale benefits can be derailed by a vocal nimby group, especially in swinging political electorates.

In addition, there are broader scale support or protest groups for virtually everything – building development, infrastructure development, environmental impact, education, social welfare, equality and more. These groups can mobilise very quickly, and the PM may be caught unawares through lack of stakeholder planning, or just simply naivety.

The development of a relevant and detailed stakeholder management & engagement plan is an essential first step in project delivery management. If the project involves internal process improvement, then the plan should morph into a detailed change management plan.

Who’s helping and who’s hindering?

→ Informally test the organisation climate for project support.

Check within the organisation to assess who’s helping and who’s hindering. Ideally, all key organisation personnel will be aligned and committed to the project, but it shouldn’t be taken for granted. Moreover, the alignment or non-alignment of key staff may not be overt, and written documentation and sign-offs may not tell the whole story. The PM should spend some time informally testing the organisational waters for any latent internal issues that may arise as the project is delivered.

You may have to develop an internal strategy to enlist the support of key organisation players to help manage and persuade the less committed internal stakeholders.

What are the key procurement and delivery risks?

→ Ensure that the project risk register is realistic and specific.

The project documentation will almost certainly include a comprehensive risk analysis – often so comprehensive that the really key practical risks are lost in amongst dozens of modest risks, or perhaps not accurately scored by the project planners. Often, the identified risk events and mitigation actions are too generic to be of much value, and they may have to be revisited to add project specificity. On occasions, some risk events may have been copied and pasted from other projects.

Check the extent of identified procurement risks and their practicality, and the risk score that has been attributed to the risk. Sometimes a thorough revision of the risk register is worthwhile, with assistance from procurement and delivery personnel. In fact, it is good practice to revisit and review the risk register at every new phase of the project, including post business case, project development plan, and then at the inception of the delivery phase.

How committed is your team?

→ Establish a competent and diverse project team.

How committed and competent is your team? Or have you actually even acquired a team yet? The team mix is extremely important. If you still have the luxury of nominating your team members, then try and ensure that the team comprises a suitable mix that demonstrates real diversity including technical orientation, process orientation, financial, social and environmental. Consider that the core full-time team could comprise a mix of generalist process-oriented and outcome-oriented people, supported by a part-time team of competent personnel representing each of the required professional disciplines. Lastly, avoid a predominance of alpha males!

The role of the Project Director

The more project-mature the organisation, the more likely that it will support the role of a Project Director (PD) who may manage a portfolio of projects each led by a subordinate PM. Or in some cases, the project may be of such size and/or complexity that a PD is appointed to a single project, supported by subordinate PMs.

If there is a PD appointed, then many of the activities identified in this paper are more likely to be directly pursued by this person, but the support of the PM is expected and necessary, and the PM’s role in these activities may not be diminished.

The role of the PMO

If your organisation is project management mature, then it is likely that it supports an effective Project Management Office (PMO) to provide the project management framework, guidelines and tools for PMs. Make the most use of their facilities, ensure your team’s compliance, and seek their personal help in managing your project structure. Don’t be shy in offering suggestions for improvement based on your practical application of their tools.

Celebrate little wins!

The daily work life of a PM and their team can be extraordinarily stressful and unrewarding, especially if some of the elements discussed here are absent. Your project will have “milestones” identified along the way, and you should take the time to celebrate the little wins as you proceed and acknowledge the work of yourself and your team as often as possible!

ECI Procurement for ICT Projects

Early Contractor Involvement (ECI) is critical for most ICT procurement projects.

The world is littered with the outcomes of horror ICT procurement examples. Media stories of abandoned or poor performing ICT projects are universal. The ICT graveyard keeps expanding inexorably. Clients have been left with sunk costs, embarrassing system outcomes and written off assets. Providers have lost reputation and severely eroded their balance sheet.

Early Contractor Involvement (ECI) is a two-stage contracting strategy that uses a combination of collaborative solution development and conventional delivery contracting. In Stage 1, the development stage, the client and provider agree to collaboratively develop the project scope and requirements, and the proposed solution. Stage 2, the delivery stage, generally takes the form of a more conventional contracting strategy, where delivery risk transfers almost solely to the contractor.

In ICT procurement failures, the most recurring critical reasons most always seem to centre around one or more of the following:

  • The client’s inability to fully express their requirements, even in outcome terms
  • The client thinking it knows exactly how to express its business and desired outcomes
  • The client’s limited technical resource and knowledge base
  • The ICT provider’s struggle to understand the nuances of the client’s business and requirements
  • The ICT provider projecting unrealistic confidence in their proposed solution
  • Failure to understand and agree how the ICT provider is intending to meet the client’s detailed requirements
  • Unrealistic expectations in prematurely seeking a competitive price from the provider
  • The client’s desire to completely shift commercial risk to the IT provider

The reasons outlined above are in addition to more generic sources of failure including poor project governance and management, and cultural issues within either the client of provider’s organisation.


Advertisement
[widget id=”custom_html-68″]

The risk of failure

The ultimate cost of the project will be driven by the quantum of professional labour applied to the task and the maturity of the components offered for the proposed solution. Unlike other industries, the provision of ICT products and services are characterised by extensive research, exploration and iteration, all very labour intensive.

The risk of failure is exacerbated by an unrealistic expectation to secure a competitive price with the minimum of time and effort, and in so doing, believing that most commercial risk will then be transferred to the provider.

The risk of failure can also be embedded by the traditional procurement methods that require several IT providers to submit a price based on the necessarily limited scope and requirements provided by the client at the time of tendering.

Providers may be forced to submit a price laced with as many caveats and qualifications as they think the client can bear. In addition, the provider’s tendered margin will have to reflect the assessed commercial risk of the project which may be very high, based on this tender and previous contract history.

Stage 1 of the ECI approach

In Stage 1, the development stage, the client and provider agree to a collaborative arrangement to develop the detailed project solution – scope and requirements, conceptual design, delivery methodology and cost estimate. The client/provider relationship is based on the successful approach used in alliance contracts, where they work closely together and share commercial risk.

If the client is required to demonstrate a cost competitive tendering environment, two or possibly three providers may be invited to develop a project solution in parallel. Of course, this approach requires significantly greater client and industry resources, and the arrangement tends to be interactive, but not necessarily collaborative.

This stage provides the opportunity for the client and provider to exchange information, questions and answers, constraints, and developing solutions. Stage 1 should not be completed until:

  • The client knows exactly what the provider is proposing to offer as a detailed solution
  • The client has confidence that the proposed solution will meet their requirements
  • The provider has sufficient confidence to price their proposed solution with minimum risk premium

For a sole ECI provider, at the completion of Stage 1, the client will award the tender to the provider provided that the client is satisfied with the proposed solution and price. With multiple ECI providers, the client will assess the solution and price offered by each of the providers on a competitive basis, and award the tender to the provider offering the best value for money.

All of the Stage 1 activity needs to be recorded for future reference, and the outcomes bundled with the Stage 2 tender/contract documentation.

Stage 2 of the ECI Approach

Stage 2, the delivery stage, generally takes the form of a more conventional contracting strategy, where delivery risk transfers almost solely to the contractor. However, this is not always the case and it is possible to continue with a collaborative relationship-based contracting strategy in Stage 2, where commercial risk is shared between the client and the provider. This collaborative approach may be appropriate when there are still a number of indeterminate scope items, or where later parts of the solution are contingent upon the successful implementation of the earlier parts.

Benefits of the ECI Approach

The key benefits to the both the client and the provider are the improvement in cost predictability, and the confidence gained in the reduced risk of proceeding with the agreed solution.

Experience has shown that the overall benefits of the ECI process can include:

  • Higher levels of control and predictability of outcomes;
  • Better control and management of risk;
  • Better control and understanding of project costing;
  • More effective control of the project schedule;
  • Better market appeal for principal providers and subcontractors;
  • Reduced potential for claims and disputes between the provider and the client;
  • Transparent costing and contingency allowances; and
  • A better understanding of the client’s requirements by the provider.

Project paralysis – the curse of the calendar

What’s driving your project development timeline? You – or your organisation’s calendar culture?

How much of the elapsed time in your project development schedule is driven by your organisation’s calendar culture, and by the apparent unavailability of key players and decision makers? How much does the electronic diary system play a part in this?
Here’s the scenario. Project Manager Jane needs to organise an important meeting. From her desk she sets up a meeting two days hence with four other invitees, including John, the key decision maker. Everyone except John responds, and John declines and adds a note that he won’t be available for another week. Jane starts the process again at a time to suit John, only this time one of the other key invitees, David, will be on leave in that week. And so on!

This set of transactions is characterised by fast electronic communication, but ultra-slow response time against the project’s critical path. In fact, if Jane has to keep doing this for each key meeting, the cumulative elapsed time for meetings will actually become the critical path! Quite bizarre!

To understand this phenomenon, you have to cast yourself back to the early 1990’s when two major events occurred to fundamentally change our work lives.

Firstly, electronic diaries were introduced as part of a suite of universally accepted office tools such as word processing and desktop databases. Secondly there was a growing trend to downsize the office assistant work group on the basis of the apparent self-servicing aspects of electronic office tools.

So mid-level managers found themselves without human support, and with the expectation that they would self-drive all of their office support requirements, including organising and scheduling meetings. Apart from some degree of increased connectivity, overall functionality hasn’t really changed since the early 2000’s.

That functionality has never really extended to some of the more subtle human skills such as anticipation, prioritisation and negotiation, that were previously available as part of the skill set of competent office assistants.

The third event that occurred was the advent of “quality management” that, if not managed carefully, encouraged the development of process as the sole priority ahead of a bias to action and outcomes, and team collaboration ahead of personal competency and accountability.

So, how can we reduce the potentially inordinate elapsed time between meetings, and thus ensure that calendar generated meetings don’t become the critical path for project development?

Calendar culture change

Culture change is not an easy undertaking, but even some relatively minor changes could have a strong positive impact. It involves instilling a greater corporate-wide sense of priorities, and/or layered program/project priorities, and an agreed “triage” system, including:

  • Agreed corporate/program priorities, based on the organization’s objectives and key risks
  • Invitees recognizing corporate and program priorities, and actively intervening to prioritize their own meeting attendance schedule
  • Organisers recognizing corporate and program priorities and negotiating timeslots accordingly – by phone or in person if necessary
  • Minimising the time demands created by functional support groups for attendance at meetings and workshops unrelated to priority programs
  • Redefining “busyness” against outcome performance and not by demonstration of a full calendar

“Busyness” culture change

In some organization cultures, a person’s “busyness” is demonstrated by a full calendar, irrespective of the nature and priority of the meetings. In addition to cultural reasons, occasionally this can be a personal behavior trait, involving the manager’s need to demonstrate their indispensability and importance. In some cases, it may also be used as a technique to avoid accountability.

Or again, a full calendar may often just be simply a symptom of that person’s lack of time management skills and inability to delegate.

Such behaviour needs to be gently challenged, and more time-worthy activities offered for consideration.


Advertisement
[widget id=”custom_html-68″]

Prioritisation and delegation

Typically for a manager, the higher up the food chain, the less accessible they are. Inaccessible managers can remedy this to some extent by practicing some basic personal disciplines:

  • Create some personal thinking time
  • Give personal priority to project set-up activities – objectives, organization framework, roles and responsibilities – where your interaction, advice, and direction is most needed
  • Publish your expectations and measures of success
  • Give clear, unambiguous delegation
  • Actively monitor roadblocks, and take early decisive action.

Clearing the decks

You can take action at a personal level to “clear the decks” within your calendar, give yourself some breathing space, and at the same time, be more accessible to others.

  • Set up your personal priority list
  • Clear out non-essential calendar invitations
  • Remove yourself from non-essential meeting mailing lists
  • Be more critical about accepting invited meeting dates and times
  • Leave some calendar space each day for:
    • urgent and unforeseen events
    • critical and creative thinking
    • personal priority time management
    • setting up delegation to others
  • Use the electronic calendar features to the max (such as subsequently declining or postponing a previously accepted meeting)

Perceived value

Key people are more likely to attend your meeting if they perceive there is personal value in doing so. So the meeting agenda, and the selection of invitees should be designed to appeal directly to the intended participants. Declining meeting attendance is an early sign that your project planning approach is losing relevance.

Corporate and project objectives and priorities can appear to be ambiguous, overlapping and sometimes mutually exclusive. Spend some time setting up your project’s objectives, relevance, benefits and development risks.

Alternatives to meetings

Most project business should be developed and managed on an interactive day-to-day basis, outside of meetings. You don’t always need to organize meetings to achieve your project objectives. Meetings should not be used to dilute or abrogate your accountability. Other alternatives include:

  • Early consideration and resolution of key objectives, risks, issues, and accountabilities, and agreement on fundamental directions
  • Negotiated and adopted individual accountability, delegation, and personal action
  • Achieving action, advice, and comments by “walking” the proposal around
  • Circulation of proposals for comment with a deadline, where silence is deemed acceptance
  • Just do it – be prepared to seek forgiveness instead of always asking permission!
  • 1
  • 2