Speaking the many languages of a project

No matter how skilled and experienced the people are in a project team, poor communication can scuttle any project.

Take the example of a recent real-life scenario, which had the project heading for disaster…

The project’s business analyst was feverishly conducting a reverse engineering process to pinpoint problem areas that needed fixing. Essentially, this involved ‘drilling into the black box, unpacking thousands of transactions’ and formatting these so that they could be understood and analysed.

The project manager (PM), on the other hand, had to regularly report to the stakeholder, using language and measurables that the stakeholder could understand and that justified the money being spent on the project.

It is here that the problem arose: business analysts think and speak in technical language, they are inherently subject matter experts. The PM needs to be briefed by the business analyst in plain English that he can understand well enough to be able to explain to the stakeholder in ‘executive speak’ (in other words, ‘sound bites’ that make sense and give the most information in the shortest time).

And there you have the root of the problem: the business analyst ‘talking technical’, providing far too much detail, to the PM who needs to ‘speak executive’ to the stakeholder, with much of the pertinent data getting lost in translation along the way.

In the case in question, the lack of communication and the resulting frustration had hampered the project team for more than three months, threatening to derail the project completely.

The situation could have been avoided had the business analyst adjusted the message, taking out superfluous technical detail and providing just the relevant information.

Effective communication between the project manager and the project team eliminates misunderstandings and ensures that everyone understands the parameters within which they have to work and what’s being delivered.

Another sure-fire way of hampering communication is to rely solely on email and other electronic communication. Experts disagree on the exact percentage of how much of communication is non-verbal (some put it as high as 93%), but there is consensus that at least more than half of communication comes from body language, facial expressions and tone of voice. Email may be useful for placing things on record but it should never be the sole method of communication within a team. And PMs that consider something done once an email instruction has been sent, do so at their own peril.

The importance of effective communication simply cannot be emphasized enough when it comes to project management. It is essential that the PM conducts regular deliverable reviews and that these are done face-to-face, even teleconferencing is not ideal. Considering that the proverbial buck stops with the PM, it falls to him to constantly reassess the project’s communication strategy and to not be afraid to make changes when necessary.

© Tony McManus, McManus Consulting.

IT project management: 101 get the basics right

Trite as it sounds: one of the most important aspects of successful IT project management is getting the basics right.
All too often, a high level view – centring primarily on the desired outcome – is taken of the project, without taking the time to put the basic building blocks in place.

These days there is a vast array of project management software available and companies often make the erroneous assumption that, having invested in the ‘right’ software, the project’s success is a given.

But utilizing effective project software is only one part of getting the project delivered on time and within budget.

Having a project plan (which includes a schedule) is critical to successful project delivery. However, even this most basic of steps is often not properly executed. In fact, the plan and schedule are often thought to be one and the same. But this couldn’t be further from the truth: the plan is the ‘how’ of the project, which controls the rules of the game; while the schedule is the ‘when’, clearly setting out milestones and the relevant dates by which they must be executed.

Simply put: the project schedule is a subset of the project plan – it is one of the elements of the project plan and details when elements of the project are to be delivered and it can be used to derive the costs of the project.

The project plan (which generally addresses the nine knowledge areas of project management) sets out what is going to be delivered, the timeframe and cost.

One of the most common problems with project management is that, due to the (often unrealistic) pressure of delivery deadlines, the project sometimes gets underway without the plan having been put in place.

With the clock ticking, and expectations high, project managers are often not given the time and space to create the project plan properly. And so, before it even gets underway, the project is undermined.

When it comes to project management and, most importantly, successful project delivery, stakeholders – from the top down – would be well advised to remember the words of the French writer, Antoine de Saint-Exupery: “A goal without a plan is just a wish”.

© Tony McManus, McManus Consulting.

King III: directors are responsible for good IT governance.

The King III report on corporate governance places unprecedented emphasis on good governance. It also puts the spotlight on the risks associated with information technology (IT); and the board’s responsibility to identify, mitigate and manage these risks.

According to King, IT should be integrated with the company’s strategy and built into its business plan.

With IT recognised as a key facilitator of achieving the company’s strategy, management must execute the IT frameworks and make sure that the IT department is on track to achieve the company’s strategy.

King III suggests that businesses develop an information security management system (ISMS). This should ensure the confidentiality of information, and the availability of information, as well as information systems, in a timely manner.

With IT playing an increasingly important role in companies’ strategies, it is important to acknowledge that the risks associated with IT have increased significantly.

King recommends that companies form a risk committee to ensure that IT risks are adequately addressed and, if necessary, call on expert advice. The committee should understand the company’s overall exposure to IT risk from a strategic and business perspective, and introduce the appropriate controls.

King calls for senior management, including directors, to be directly involved in IT governance. And this has given rise to the increasingly prominent role of the chief information officer (CIO). Since many directors have limited understanding of IT systems, it is recommended that the CIO sits on the board.

Effectively this means that the board has access to a thorough technical understanding of the IT risks, while the CIO is exposed to the company’s strategy at the highest level and can play an active role in integrating IT into the overall strategy.

© Tony McManus, McManus Consulting.