INTERFACES

Interfaces are the relationships between two or more people within a project. Understanding what is happening at these boundaries is important because it is here that information is passed about within the project. By examining the interfaces you are able to determine what information you are likely to want to know about. Obviously not all of the information passed back to you will be relevant; however, it is relatively simple to set up systems that dispose efficiently of unwanted information.

A more common way of considering interfaces is to examine the stakeholder relationships within the project. This is using the term ˜stakeholder' in the very broadest sense. It uses the term to include both project team members and those with any interest in the project and its outcome. Stakeholders fall into two categories, internal stakeholders and external stakeholders. The internal stakeholders are people within the sponsoring organization but normally outside of the project. The external stakeholders are companies, organizations or groups of people outside of the organization. Both groups of stakeholders need to receive and discuss information. However, it is usual for the internal audience to be more directly involved in the project work.

Internal interfaces

Internal interfaces deal with the relationships that happen between members of the project team. Generally this is all of the interfaces that occur inside the sponsoring organization. It is likely that there will be a substantial number of these interfaces. However, each interface will normally fall into one of two groups: either interfaces between groups within the project or interfaces between individuals within the project.

Interfaces between groups within the project are caused by dependencies between different tasks . For example, a test and integration work package will obviously rely on the result of another work package. The other work package will need to deliver to the test and integration work package to allow it to complete successfully. This inter-dependency between work packages is clearly an interface that must be managed effectively. If it is not monitored and action taken when things go wrong, the overall project could be seriously affected. Although the planning will have identified these dependencies, it will not have dealt with the need to manage the dependency interface successfully.

Managing the interface effectively is achieved by examining the resources that are being deployed across the boundary between the work packages. These resources will be people, some kind of material or both people and material. Material might be hardware, software, machinery, etc. The first step in determining what is happening at the interface is to write down all of the information that is likely to pass across the work package boundary. Generally this information is already available from the initial planning. However, it is good practice to review the information with the work package managers of the work packages involved. This review should take place in the context of interfaces rather than a background of simply revisiting deliverables. This will help to ensure a focus on information flow.

Once the information has been identified a chart can be drawn up. This chart should look something like the one shown in Table 6.4.

Table 6.4: Information passing across work package boundaries

Originator work package	Destination work package	Frequency of information flow	Importance of information	Description of information	Key dates	Comments
Core application	Integration and test	High	High	Need to assess constantly the ability of the core to pass the mainline assessment	Once every two days
UI design	Upper application	High initially, low thereafter	High	Design specification is essential	As per work schedule	This is a two-way information stream. The design needs to be sense-checked
Integration and test	Product realization	Low	Medium	Providing information to allow documentation to be produced	As per work schedule	Will become of more significance near end of project

Creating a chart like this can seem a tedious process that might not add significant value. This is especially true if every piece of information that flows across the interface is captured. However, the creation process does not have to be long or difficult. Good project managers should be able to capture this information as they meet with the various work package managers. The process is simple if a chart similar to the one shown in Table 6.4 is used as a template.

When talking to work package managers you should be careful only to capture information where there may be an issue. You should remember that too much information can be as bad as too little information. With too much information it can be difficult to understand exactly what is going on. Therefore when completing the chart you should triage the information and only include information that needs constant attention.

You should agree a schedule with the various work package managers for the review of the information flows. This schedule not only sets time aside for reviews but it also encourages work package managers to take more interest in other work packages. You need to remember that it may not be obvious to work package managers that failure to deliver across the interface, on a specific time or to a specific quality, may cause problems. They may view a one- or two-day slip as being acceptable. For example, a team member is working on the software development work package and is scheduled to move on to the test and integration work package. However, the development is running late and the team member cannot be released at the given time. This means the overall timescale for the project slips for every day of unavailability - a simple problem to resolve if captured early enough.

As part of the analysis of the internal interfaces you should look at the relationships between the individuals involved in the work packages. It is often these interpersonal relationships that are the root cause of any interface problems. This can extend beyond simple one-to-one relationships to include teams that do not communicate or try to work together. Analysing the personalities is an area of work that project managers do not often undertake in a formal manner. Instead they have brief discussions to try to figure out who are the ˜difficult' people. These ˜water- cooler ' discussions are not the best way to resolve the problem.

Assessing the personalities

Skilled project managers should be able to apply a systematic approach to identifying personalities and potential clashes within teams. They should be able to categorize the various team members according to personality type. Most project managers will undertake this assessment naturally when they meet team members. This assessment will normally be made at an unconscious level. To enable project managers to apply a systematic approach they need to raise the assessment to a conscious level. This is achieved by adopting a framework within which to rate the various people being assessed. The framework sets out the personality characteristics that you should look for in an individual. The personality types to look for are: idealist, factual, traditional and chaos.

• Idealist

  Idealists are people who look for perfection in the work that they do. In a project they are normally the people who are good at the initial requirements setting. They will push others to think continually about what is being produced. These personalities value accuracy and improvement and they make teams focus on producing a quality product.

  Idealists can however cause problems in project teams through their constant desire for perfection. They cause others to despair whether the work they are producing will ever be good enough. Others feel they are being constantly judged and as a result they tend to prefer not to work with idealists.

• Factual

  Factual character types base all of their work on facts and the rationale behind the facts. Generally they go into questioning mode very quickly, trying to find out as much information as possible. One of the main benefits of this character type is that it is an action-orientated character type. People with these traits tend to go to work on issues rather than working them through using abstract models.

  Factual people can however be viewed as being aggressive and argumentative. This makes them unpopular, especially if the character trait is strong. Team members often feel threatened by this character type because they are always being asked to justify themselves to this type.

• Traditional

  Traditional character types are the peacemakers. They will strive to build consensus and agreement. Often this character type is excellent at chairing meetings or sorting out sensitive issues. One of the best uses for this character type is in dealing with project stakeholders.

  Traditional characters do however fail to push issues forward. Since they do not like confrontation they tend to hold back on pushing others into making a decision. This can make it difficult for the project if they are in charge of a high-risk item of work.

• Chaos

  These character types like to be free to do whatever they want. Often these people are charismatic and as a result they enhance a team's motivation. Their desire to be free drives them to be creative and spontaneous , making them very useful at problem solving.

  The obvious negative attribute for this character type is its dislike of any sort of plan. These people believe that it will just happen and that planning is not a worthwhile activity. This makes them extremely difficult to use when a plan must be delivered to a schedule.

Analysing the personalities

It would be very time-consuming on a large project for you to undertake an analysis of the personalities of each team member working on the project. Instead you need to rely on your work package managers for the analysis. You should ask them to look at their teams, using the classification, and then get them to use the characteristics to enable better team working.

In some cases you may find that the character make-up of the team is poor. Perhaps everyone on the team is a chaos character type. When this happens you need to work with the work package managers collectively to move team members between teams to achieve a more balanced team.

External interfaces

External interfaces are interfaces with companies or organizations that are outside of the project team members. The external interfaces fall into a variety of categories: suppliers, stakeholders, partners , customers and other interested organizations. The external interfaces are often as important to the project as the internal interfaces. It is possible that much of the project work will be undertaken by people who are external to the organization. For example, a software company building a new headquarters is unlikely to build the building itself. Instead it would hire architects and builders. When external companies or organizations are used in this way the external interfaces need to be managed effectively.

To ensure that the interfaces are properly understood , the project manager needs to analyse them. This should be done in a similar manner to the analysis of the internal interfaces. This means that the interfaces between the external party and the project need to be identified and listed. Each interface should be examined and the information flow across the boundary determined. This analysis can be undertaken using the internal interfaces chart (see Table 6.4). Wherever practicable this analysis should be undertaken in conjunction with the external company or organization. For example, a supplier may be expecting a delivery from someone within the project on a particular date with a known level of quality.

Once the analysis is complete, both parties should review the information flow description to check that it is correct. They should then determine how they are both going to ensure that the information flow occurs in a timely manner. This might be as simple as a weekly phone call or it may involve a more complex delivery schedule.

The key to managing the interface is to understand the underlying purpose of the interface. The purpose could be simply to pass information across the interface to make the people involved feel informed. For example, building a new airport terminal clearly requires that the people in the surrounding area, project stakeholders, are kept informed. They are not strictly part of the project but they will care deeply about the progression of the work. If the project fails to manage the interface well it could end up with protestors on the airport terminal building site.

Whatever method is chosen , both parties need to remember that the project will change repeatedly. This means that both parties must commit to regularly reviewing the information flow. They need to ensure that the boundary information remains current and useful to both parties.

Reporting

Reporting is an essential part of keeping the interfaces of your project working properly. When the reports are properly conceived they enable you to measure the success or failure of the work being carried out. They also ensure that there is good-quality information available to aid the information flows within the project.

Despite its benefits, reporting is often dreaded by project managers and their teams. They see it as a chore that gets in the way of the ˜real' work. Despite how the teams may feel, reporting is an essential part of advanced project management.

Reporting enables those outside of the project to determine what is happening and whether everything is going according to plan. Additionally when it is used effectively it provides a channel for the project manager to pass helpful information to the project team and the stakeholders.

Writing reports

When writing reports authors should ensure they understand who their target audience is. For example, many project managers produce weekly reports for the benefit of their project teams. Then they simply reuse these reports when providing information to stakeholders. They don't account for the different audiences and often the result is problems with stakeholder relationships. You need to take time when dealing with stakeholders. You must understand the audience and the effect the audience can have on the project. You need to understand the type of information the audience wants and the level of detail that is required. For example, it is acceptable to use abbreviations and project ˜buzz words' in reports destined for the project team. However, sending the same report to external stakeholders is almost certain to result in difficulties. You would need to include a glossary or similar to explain what everything meant .

There are many types of report required during the lifetime of a project. These range from standard weekly reports to more specialized single-topic reports.

Types of report

Weekly reports

Weekly reports present the progress of the project. They should gather together information about the various project work packages and should provide detail for each part of the project. They should examine how the project is progressing in relation to its overall milestones. The progress report should show the actual plan against the baseline plan and should highlight and explain any differences. It is important that the baseline plan is tracked since it is this that will give an impression of how accurately the project is sticking to its estimated timescales.

You should work with your work package managers to design a reporting system that allows them and you to produce weekly progress reports easily. One of the most effective methods for designing the reporting structure in an advanced project is to design it in sympathy with the work breakdown structure. This ensures that the reporting is based on a project model that the majority of the project readership will not have to learn. Setting up a structure that is sympathetic to the work breakdown structure is straightforward. The project manager should set up a series of reports, creating one report for each low-level work package. This report is then passed to the more senior work package and a summary report created. This is illustrated in Figure 6.11.

Figure 6.11: WBS outline

Reports detailing work package information focus on the output of individual work packages. Each work package is analysed and a summary given setting out the position of the work package. It is important that the work package sets out the information in relation to the original plan. This ensures that the readers understand whether the plan is being successfully executed. The information provided in the report should be concise and clear in its presentation and it should clearly reference the initial work package order.

Monthly reports

Monthly reports provide a summary of all of the weekly reports that fall due within the month being reported . Unlike the project team members, most stakeholders are working full time on non-project activities. This means that they do not have an enormous amount of time to keep up to date with the project position. As a result they tend to prefer monthly reports to weekly reports. Usually they only want weekly reports when something major is happening or when something has gone wrong. Monthly reports fall into four categories:

• in-depth reports on risks and problems;

• in-depth reports presenting the monthly status;

• general reports;

• overview reports.

• In-depth reports on risks and problems

  In-depth reports are normally produced in response to a requirement to investigate an area of the project in detail. These reports are designed to enable senior managers or stakeholders to gain a detailed insight into areas that may cause significant problems within a project. The reports concentrate on the high-risk areas within the project and they are usually produced on demand rather than as part of a fixed reporting cycle. Most advanced projects will produce a number of these reports every month covering different topics. The reports can be categorized in two ways: either to assess potential risk or to find out why tasks went wrong.

  When the reports are used to assess potential risk they are usually completed in advance of the start of the work being assessed. This normally gives the project manager time to act to mitigate any significant risk to a given task. In-depth reports used in this way are often requested by stakeholders prior to major milestones. When reports are used to assess why tasks went wrong, normally someone outside of the immediate project team undertakes the reporting. Using an independent person helps to ensure impartiality and it is always good to have someone new examine the problem. In-depth reports used in this way are normally requested by the project manager or the project sponsor.

  Since this report can cover a variety of topics it is difficult to create any form of standard template. You should ensure that it covers the fundamental building blocks of projects: timescale, resources, quality and scope. Equal space should be given to each area within the report to ensure that a balanced view is presented. The final report should be short and as a result needs to be succinct and clear. You should ensure that authors of reports understand this. They need to appreciate that an in-depth report is not the same as a report that presents every detail of the problem or risk. The purpose of the report is to provide an analysis not to make the reader an expert in the topic area.

• In-depth reports presenting the monthly status

  In addition to in-depth reports on risks and problems there are also in-depth reports that present the monthly position of the project. This monthly review gathers together the key information from the weekly reports and presents it in a summary form. This monthly review allows senior managers to review the strategy of the project. Unlike the weekly reports, the monthly report ensures that readers are able to take a ˜helicopter' view of the project. This enables them to spot problems that can't be seen from the ground. Additionally it helps stakeholders get a feel for the forward movement on the project, something that is hard to do only reviewing the week-by-week reports.

  This in-depth monthly report and its associated review often becomes one of the most important parts of an advanced project. Frequently it is released prior to the steering group meeting and as a result it guides the focus of the meeting. Issues and difficulties mentioned in the report are almost certain to be discussed. As a result providing accurate information for that monthly review is essential.

• General reports

  General reports provide high-level summary information to a variety of people. They supply basic information about progress and deliveries. General reports are most often used for external stakeholders, for the general public or for internal staff information distribution. These reports present information in a very cautious format. They do not offer information that might give the reader a negative impression of the project. Instead these reports are used to present the project to the outside world in a manner that gives those outside the project confidence.

  Unfortunately restrictions sometimes have to be applied to this type of report. These restrictions stop the project releasing information that would explain clearly why things have been undertaken in a particular way. This can cause problems. Barriers to releasing information can occur from a variety of sources. For example, the project may be a secret government project that involves the building of a nuclear power station. Or it may be the destruction of some national monument that will result in a public outcry. Where a secrecy requirement exists it can be very difficult for the project manager to provide public information that is accurate. When this happens you should provide the information that you are allowed to supply. However, you should additionally prepare a strategy for the adverse reactions that happen when the true or full information becomes available.

• Overview reports

  Advanced projects regularly introduce a new or advanced concept within an organization. It is therefore important that all the senior management within the organization understand what the project is trying to achieve. When managers are aware of the contents of the project they are able to act as ambassadors for the project within the organization. They are able to explain clearly, accurately and quickly what is happening when they are asked by people who are not working on the project. The final type of monthly report is provided to give support to these managers.

  The overview report's purpose is to educate those senior managers who are not involved in the project. If the report is correctly pitched it can help to ensure that they gain a level of understanding about the work taking place. Overview reports can also be useful to other projects that are either dependent on the project or are working in harmony with the project. Overview reports should provide information that can be ˜drilled' through to enable other information to be found. For example, it may discuss a work package and have a reference to a point in the work package weekly report.

If project managers lead reporting effectively they will provide confidence to the people involved in the project. Regular communication that is clear and targeted and is provided on time will enable the project to progress smoothly with the support of its stakeholders. Project managers can drive this communication through the effective use of these four report types.

Risk reports

An integral part of progress reporting is risk reporting. This activity is essential if the project's progress is to be accurately understood. Risks come in all shapes and sizes and this often means that it's difficult to know what risks to report. There is no one simple solution. However, as with many areas of advanced project management there are tools that can help.

Table 6.5 shows a simple grid that assesses task risks. As with most areas of advanced project management, this focuses on the fundamentals:

• timescale;

• scope;

• quality;

• resource.

Table 6.5: Risk table

Task description	Impact	Urgent
Scope	High	Yes
Timescale	Medium	No
Quality	Low
Resource

For each fundamental the impact and the urgency of the risk are assessed. You should remember that this tool can only provide an indication of where some problems may be. You should however not rely on this or any other tool. You should remember that perhaps the most important indication of problems is your own intuition. This and other tools should simply be a mechanistic way of sense-checking your intuition.

In an advanced project it is likely that there will be a substantial number of medium and low risks. As a result you should restrict yourself to reporting the risks that are pertinent at any moment in time. This means using your judgement to assess which risks are worth reporting and which risks are not. This can be easily assessed by thinking through how soon the risk is going to affect the project. If it is not going to affect the project in the immediate future then the project manager should probably not report on that risk. Risk reports can become very large if project managers are careless with the information they include. To ensure the reports are meaningful it is important that project managers are judicious with the information they include.

Budget reporting

The major cost in most projects is people. This ensures that it is almost always one of the areas where reporting is required. A simple but effective report is simply to profile the resources against time. This is shown in Figure 6.12.

Figure 6.12: Cost reporting

Although this graph presents only a small amount of information it nevertheless is extremely useful to a project manager. Firstly, it enables you to assess the forecast and the actual spend . Secondly, it allows you to anticipate potential problems.

The first use is self-explanatory. You should simply assess on a regular basis whether the spend profile for the project is being achieved or not. If it is not then you need to start to investigate the reasons for failing to hit the profile. Investigation is the second use for the graph. It allows you to determine what is going wrong. This happens when the actual graph is different to the planned graph.

If the actual line is above the planned line then more resource is being spent than was planned. This could have a simple explanation. Perhaps overspend resulted from poor original estimates or work has progressed faster than anticipated and so people have been brought in early. However, the explanation might also be that the project is falling behind schedule and extra resource is being added to attempt to stay on plan.

If the actual is below the planned estimate, again it may be simply poor estimation. However, it may also mean that there are problems. For example, perhaps people are not being used because the work hasn't progressed enough to enable them to start. Whatever the reason the difference in the graph would make you investigate. You must be careful with the investigation since projects rarely hit their estimates. This means that using a precise assessment of the graphs is unwise. Fortunately there is an easy method for overcoming this problem. This is achieved by using tolerance zones similar to the ones shown in Figure 6.13.

Figure 6.13: Cost reporting tolerance zones

Figure 6.13 shows a graph with an upper and a lower tolerance zone. When the project goes outside one of these zones you need to investigate. This simple method can be adjusted depending on the amount of risk the project manager wants to take. A wide zone allows for larger risk than a narrow zone.

Including a tolerance zone has the additional benefit of giving the report's readers reassurance that the risk is actively being managed. It also allows them to assess for themselves whether the risk being taken is too great or too little. Depending on their views, they can make appropriate representations to you.

Management summary

Management summary reporting covers the top-level activity in the work breakdown structure. It is a summary of all the project reports. Normally the readers of this report are senior managers within the organization who commissioned the project. Unlike the reports discussed so far, this report should not be structured around the work breakdown structure. Instead the report should concentrate on the fundamentals of the project: timescale, scope, resources and quality. For each of these areas the report should explain the current position in relation to the planned position. It should also explain the risks going forward and how they will be mitigated.

Some companies have a standard template for this type of report. Where this isn't available a format similar to that of Figure 6.14 could be used.

Figure 6.14: Management summary report

Project team information

The final and one of the most important areas of reporting is the reporting of progress to the project team. Ensuring that the project team know what's going on in the project is essential for building clarity, purpose and motivation.

Effective communication across a large project team can prove to be difficult. It is not possible for the project manager personally to brief each team member. Instead the project manager needs to rely on the work package managers.

Normally the most effective way of briefing the project team is through cascaded briefings. This should be related to work packages. So the work package manager briefs his or her direct team who in turn brief their team and so on. The project briefing should present the overall picture of the project and then it should concentrate on upcoming activities, their risks and the associated mitigation.