Saturday 23 May 2015

BT Dark Fibre

It is interesting to note that Ofcom, the UK telecoms regulator, is opening discussion/consultation with a view to opening British Telecoms (BT) fibre network to competitors for business network links. Essentially Ofcom is tired of the excuses from BT OpenReach and its failure to deliver installs in a timely manner.

This could see some real competition in the business telecoms industry. It will be a bit like the shake up of telecoms in the City of London back in the mid 1980s. It is a £2 Billion market at risk.

The consultation closes 31st July 2015.

Sunday 17 May 2015

Project Milestone Deliverables and Due Dates have not been documented - Early warning Signs of Project Failure

It is possible to plan a project and its project activities in detail without setting Milestone points in the plan. Provided that all of the activities are completed on time and to requirement it is possible to complete the project successfully on time, with full functionality and to budget.

However, most projects are so complex or undefined in the early stages it is not possible to rely on a finely detailed plan. The beast is too complex and people outside of the project office, such as the stakeholders can find it difficult to accurately understand the real level of progress. A mix of problems and delays can lead to serious project damage before anyone in power has realised there's a problem.

One effective way of dealing with complexities is to group important items at set a marker date or "Milestone" by which the group of activities must be completed. You also need to define in advance some "deliverables" for each milestone so you can assess whether or not the Milestone date has been met. Without a list of deliverable features/actions it is not possible to challenge the assertion by the project team that a Milestone has been met.

When you define a milestone you are declaring an easily understood and obvious measure of progress. The milestones are generally those which a business manager would understand. The deliverables need to be tangible items/services/facilities which can be independently verified as "delivered". When a Milestone has been reached, the project team and stakeholders can decided whether sufficient progress has been made or whether some variation is necessary for the project. If a Milestone  and its deliverables move past the due date it is cause for concern.The most difficult case is to realise that the organisation needs to abandon the project or consider some other serious variation to the project plan of resources.

If the project team does not have documented clear milestones which are subject to review it is probably a sign that there is insufficient control and the project may drift off course.

Friday 15 May 2015

Project Stakeholders not interviewed for requirements - Early warning signs of project failure

When checking the health of a project you need to establish that all stakeholders have been interviewed to establish their requirements of the project. If these interviews have not taken place it is an indicator of potential project failure. It can lead to incomplete functionality and function creep.

The interview results should be documented and signed off by the Project Manager and the Stockholder.  The process should ensure "informed consent" so the Stakeholder understands the process and the implications of the information he/she is providing. The interview process should provide iterative feedback where the analyst double-checks the information gathered.

It is helpful to have a structured process for the interview to establish full information and also the level of confidence in the data provided.

The documented requirements should be cross referenced to the proposed functionality, projected delivery time-scale, performance and reliability projections to enable the Stakeholder's   understanding of whether what is proposed will meet his/her requirements.

The project team should also document any requirements expressed by the Stakeholder which will not be met by the project. These gaps should be discussed with and signed off by the stakeholder.


Wednesday 13 May 2015

Dusty builders in your technology room

We've been involved in many projects where a data centre room is built from scratch in a bare concrete building skeleton. There are many challenges involved in such projects, but the most insidious problem is dust created during the construction process. It gets everywhere; on floor slabs, ceiling voids, ducting, even installed cabinets. You need to have a clean room environment before the installation of servers and network equipment. It can contaminate fan bearings, printed circuit board surfaces If you install in an environment containing dust you risk premature equipment failure and malfunction.  It clogs filters in air conditioning units.

Once you get the room dust free through specialist cleaning of floors, voids, walls and ceilings it is difficult to keep it clean. Ideally you need to ban tradesmen/craftsmen from working in or entering the clean room once it has been fully cleansed. In practice however there will always be something delayed or forgotten which creates extra construction work in your precious "finished" room. If it is essential the contractors undertake any dust creating work you'll need to consider dust control tents, with dust extraction air handling, to enclose their work area. Their method statement documents should always detail how they'll control dust. Before releasing the work area you'll need to ensure appropriate cleansing to ensure the effected area is dust free. 

People carry dust on their clothes and shoes from the environment outside of the clean room. This is particularly the case if they've been involved in or working close to dust creating activities. You can use tack-mats inside the entrance doorway to trap dust from shoes. The mats need to be checked/renewed daily to ensure they're functioning properly. You also need to police the use of the tack-mats to make sure people are using them.

Disposable coveralls and booties for shoes will help to contain contamination dust, but tend to be unpopular with tradesmen if they need to frequently enter/leave the clean room. You'll also need facilities for people to change into and dispose of the cover clothing.  There are costs of these disposable items.

After some experimentation we devised a temporary two door air lock solution. The floor of the air-lock contains dust removal measures such as bristle mats mounted on a grounded metallic vacuum plenum matrix. The air lock chamber is temporarily assembled inside the main entrance to the clean room . As people enter the room, air knives blast air from their clothing and shoes. The bristles brush their shoes as they walk across and the underlying vacuum floor sucks away dust laden air through the bristle mat.

We treat the air by passing it through a dust vortex chamber and then on to a MERV 11 HEPA filter chamber to clean the air before returning it to the clean room. This arrangement does not alter the air pressurisation of the clean room. The vortex chamber extracts 99% of dust leaving the finer residue for the HEPA filter but it drastically reduces the maintenance needed to support the HEPA filter (extends life). The dust captured by the vortex chamber is dumped in a sealed container for easy removal by low skilled workers. The filtration unit requires about one kW of power to operate and cleans about 1500 cu metres (53000 cu ft) of air per hour within the airlock. It is possible to buy particle counters from upwards of £300, but typically circa £2000, to validate how effective the control measures have been.

The temporary airlock also helps to control dust which can enter when the external doors are opened. We have experimented with providing a vacuum table station where items/clothing being carried into the room can be cleaned. The vacuum tube is serviced by the main airlock filtration system. In operation we found this approach effective but needs policing to ensure workers use it. Providing a small translucent vortex unit and dust container at the vacuum station gives a low cost overt demonstration to both workers and management.

When the construction activities are complete we can knock down and remove the airlock, or if desired incorporate it as a permanent feature of the room. The construction of the unit has to be robust to support the weight of heavy equipment which may be wheeled over it. The air handling of the temporary airlock is self contained, avoiding the need to modify the permanent air handling and avoiding making any new holes in the fire resistant wall.


For those who want to experiment with this technology, here's one low cost approach using a kit:



 In the USA you might want to look at the Oneida range of vortex units, for example the Dust Deputy. We used vortex devices made from steel to be able to withstand the rough environment on a construction site. They are more expensive, but do a good job. When using this technology around servers or network equipment be sure to use anti-static counter-measures and good electrical grounding. The swirling dust in the air flows can create a hefty level of static electricity.

Tuesday 12 May 2015

Poor Change Control - Project Failure Early Warning Signs

Few organisations have the resources to mount projects which have no change control process. Unauthorised changes could affect the budget, delivery time scale, resources, performance, functionality and operational costs of a project. In some cases there are legal, compliance, audit and regulatory constraints which have to be planned and controlled and delivered as part of the project change. Without project controls, proper cost benefit analysis of changes, prioritisation of development and release efforts for changes it is very easy for projects to go astray, bust their budget, have late delivery and limited/excessive functionality.

There may be complaints from developers, business users/clients that the change control process reduces flexibility in a project. Usually the risks of project failure from the lack of robust project control massively outweigh any gains from "flexibility".

The control process also helps to track the associated costs of any change. Such costs can be obvious, as in "x" man hours of additional development/testing effort, but they can be more subtle such as:

  • the impact on system performance requiring an upgrade or alteration of system infrastructure;
  • changes to support software licensing and maintenance costs;
  • costs of consequent delays to system functions/services; 
  • or maybe there is a long term impact on operational costs;
  • the costs associated with releasing the change to a stable environment;
  • training costs to allow personnel to accommodate the change;
  • knock on changes to archive/retrieval systems to meet compliance needs;
  • modification of data migration planning;
  • changes in one part of a system might necessitate changes to another system.

The control system should provide a documented authorisation pathway showing who has assessed the impacts, who has authorised the work and who will pick up the immediate and long term costs of the changes. It is all too easy for a business user to go "transparent" and say: "I said it would be nice if.... but I didn't agree to these extra costs/delays arising from the changes".

The authorisation of changes, the impact assessment, the implementation planning and progress of changes should all be tracked. Where the work is performed by external contractors it is essential to track/control the changes in order to be in the position to challenge bills presented by the contractors for "variations" at the end of project or the next round of billing.

Weak Project Manager - Early Warning Signs of Project Failure

When a project team has a weak project manager who cannot effectively lead the team or is poor at communication with the clients/business management it is a strong early warning sign of IT project failure. 

Early in my career as a technology development manager I used to dislike several project managers. They were bossy, abrasive, pointed out my faults and seemed to spend ages just chatting with business management. These people seemed to flout the established departmental rules. What I came to realise was that these people were in fact great project managers who delivered projects on time, on budget and good functionality.  They had good communications with business management and made sure the technology aligned with business needs. In managing the teams they were intolerant of excuses or lack of clarity. These project managers wanted to know about genuine problems so they could martial appropriate resources to handle the issues, they were supportive when things go wrong. They provided leadership while possessing sufficient technical skill/experience to manage and motivate a multi-discipline team of engineers.

I am often called in to rescue projects that have gone wrong. They are late, over budget and or the team is poorly motivated. The business management executives may have lost confidence in the team. One of the first things I examine is the Project Manager. Does this person demonstrate the skills necessary to lead the team and communicate well with the client? Does he/she maintain team discipline and have a tight grasp on progress? Is he/she too tolerant of excuses for failure to meet delivery? Does the PM control the scope of the project and the budget?  Without a good leader it is inevitable the project will drift off course.

I've seen situations where the project manager has excellent academic qualifications in project management techniques but just lacks the necessary leadership, communication and control skills. They've often been relieved when I take action to remove them from the leadership role. I'll usually try to rescue such people and give them opportunity to develop their skills as a supporting team member. It's (usually) not their own fault they were given a role beyond their capabilities. 

A different problem can arise when the Project Manager lacks the necessary technical skill. They may be a great leader, but lack the knowledge to question the progress reports provided by technical team members. In these cases team morale can be destroyed as progress is falsely reported or resources are poorly allocated. I saw a case recently where repeated failures to meet application program delivery dates were not challenged by the Project Manager, the team just rescheduled, shuffled priorities and added more contract staff. The underlying performance issues were not addressed. The project ran over a year overdue, had reduced functionality and was massively over budget.

Monday 11 May 2015

Requirements and scope not documented - Early Warning Signs of IT Project failure

It is important to to define in writing in the initial stages the expected functionality arising from an IT Project. While this definition might not be fully detailed at this point, until the analysis/design process has been completed, the requirements should be sufficiently descriptive that any non-IT manager can understand what is proposed. The initial documentation should describe the scope of the project. It should also describe any important business features not included at this point. 

In today's environment of 24/7 on-line, web based and social media applications the requirements should specify the performance and reliability expected of the system.  I've seen several projects where the leaders can produce massive dense documentation on the functionality of the system, yet no real detail on the expected performance of the system. It is crucial to understand the costs of appropriate performance levels and reliability right from the start of a project. It can be very difficult to retrofit performance/reliability into a system if this has not been considered from the outset.

One of the many budgets used to control a project might well include a performance budget where the resources and infrastructure required to meet the projected processing and response times of each major component are monitored.

It is important the business signs off those functionality/ scope/ performance/ reliability requirements at the early stages of the project. It is important that this is "informed consent". One of the responsibilities of the Project Manager/Director is to ensure business executives understand what they are signing off and have the time to question what is proposed. Real signatures should be on a document recording that agreement. 

Sunday 10 May 2015

Early Warning Signs of project failure - Lack of Senior Management Support

Throughout my career I've had to help on projects giving technical advice. You can soon notice some early warning signs of an IT project running into trouble. If his/her brief allows, the consultant can assist the client by alerting to them to early warning signs of problems.

One of the most serious is a lack of top management support or commitment to a project. Typical signs of this is the absence of senior managers at key steering group meetings, or a failure of the senior managers actively tracking progress of the project. If the managers are content to "leave the project to the experts" it is a recipe for disaster.  During the life of a project challenges will arise which need the active involvement of the business for business decisions and possibly resource allocation. If the senior managers merely passively receive progress reports from project managers it may be a sign of problems.

The senior management involvement should be there right from the start of the project. This will help to ensure the alignment with the planned direction of the business. The executive can help to champion the project at Board level when resources are required.