In business, as with most things in life, change is constant. When an organisation needs to make an important change, like upgrading a computer network or expanding to a new location, it's usually best to view it as a project. Size, of course, isn't what defines a project, but what does define a project is a plan.

There are many, complex reasons why projects fail but if you get the planning stage right then that is one more reason to help you succeed so your project does not become one of the ones that never delivered on its outputs and outcomes.

A project can be defined as any planned undertaking with a set of related tasks designed to reach a defined objective that has both a beginning and an end. Without a plan, a project becomes just an assortment of tasks. For most organisations, the question isn't whether or not there is a plan, but how well the plan has been set out and how well it is followed.

A lack of planning will always contribute towards an unsuccessful project whereas good planning leads to successful projects. By clearly defining the project aims, objectives and requirements in the planning phase, and by creating an achievable schedule, appropriately sequenced and associated dependencies identified, you are more likely to succeed in delivering the project objectives. That sounds pretty simple yet so many project managers rush the planning phase – often due to external pressures – and the project is then set up for failure. A poor plan will never deliver good results.

The following are key elements of a good project plan:

Objective: 
A project should have a primary objective (i.e. the end result) with a specified budget, schedule and requirements. A project may be broken down into additional objectives leading toward the primary objective. So it is best practice to structure the plan as batches of 'deliverables' (project requirements) broken down into tasks (there are properly sequenced, dependencies identified and resource assigned) that deliver the deliverables. The last task in that batch is always a milestone. this format ensures project managers have always has good line of sight to objectives, requirements and key milestones, to track progress. It also avoids the need to have a separate requirements traceability matrix.  

Project Milestones: 
A good plan will include milestones to help monitor progress and provide the opportunity to re-evaluate deadlines, scope and deliverables, if necessary, or provide confidence that the project is on track. It helps avoid bottle necks when there are complex inter-dependent tasks so ensuring the project can advance to successive phases. A good plan helps compare the original aims with current progress – it is highly likely that your plans will change during the course of the project (rarely do original plans deliver as expected) but a sound initial plan ensures smooth transition to a new plan that will deliver successfully, and will add certainty that the project has delivered successfully. This avoids the situation where a project is finished yet doesn’t “feel” like a success.

Stakeholder Commitment:
Projects often have several stakeholders with different priorities but a good project plan ensures all of their priorities are considered and included in the overall vision of the project. This helps ensure stakeholders are fully committed to the project and will work to drive progress forward – without this stakeholders can become disillusioned about the project and not be there when you need them.

Contingency Plan:
Another element of good planning is incorporating a contingency – both within the budget and the schedule – to account for unforeseen problems that might arise, because things can always go wrong. Without a contingency plan the project is running a real risk of failing to deliver because no allowance for additional costs or time mean that scope and/or quality will suffer, resulting in a deliverable that does not satisfy anyone’s needs

In a nutshell, a good project plan should provide a roadmap for every aspect of the project. Amongst other things, it:

• Defines what tasks need to be completed, how and when
• States who is responsible for each task
• Provides a mechanism to monitor and track progress
• Gains commitment from stakeholders
• Has a defined contingency plan for all eventualities
• Defines communication channels

Over the years, I've had various requests from many colleagues and clients alike asking for the 'magic formula', to ensure they themselves can deliver projects successfully. The fact is (and sorry to disappoint), there is no such thing. Project Management is a profession, like Accountancy, HR or Operations, that takes years of practice to accumulate necessary experience and earn internationally recognised qualifications; that allows one to manage projects effectively.

But like other professions, there are basic, common sense approach that one can take to ensure you have better chance in achieving success. So, for the mass of 'non-project managers' who often get lumbered with a 'project' to deliver by their organisation, I thought I'll post this as an aid. (But only use it for small, non-complex project. Anything else, leave to the professionals).

Instead of setting out the fundamentals in a list, and bore you; I thought instead I'll set it out as a video below. However, note that I only set out the very basic steps and have intentionally avoided key project elements (and jargons) like 'creating network diagram' or 'identifying critical path?' or 'how to manage project performance' etc; in other words, it is set out in layman terms and excludes many things that any project managers would be familiar with (and as a result probably will be crying out 'blasphemy' at this article).  But it should serve its purpose in ensuring you get the fundamentals right.

So enjoy:

The challenge in preparing any culture for change is that staff tend to cling to the present state (where they are now). One of the biggest obstacles in getting folks to move with the change into the future state (where you want them to be) is that the present state is usually fairly comfortable. Unfortunately, getting them to move is not as simple as just asking. In order to get folks to move from the present state to the future state project managers need to understand the stages that incorporate the “Why, Where, and How” of change.

In general, the most fruitful success strategy is to begin with leadership tools, including a vision or story of the future, cement the change in place with management tools, such as role definitions, measurement and control systems.

If staff don’t understand why they need to change, they won’t change. This is why, ironically, it’s often easier to lead a change management effort in a failing business than in a successful one. If the business is heading towards downturn, it’s a lot easier to explain why we need to change. But in successful organisation, staff will often say, "Why do we need to change if we’ve been so successful thus far?"

Often the first thing project managers need to do to prepare the organisational culture for change is to set the imperative. In other words, explain why the present state is significantly less comfortable and the need to change. Maybe it’s as simple as pointing out that there are coming threats to our current success. Maybe it’s pointing out that we’re not really as perfect as we think we are.

If the present state were less favourable, staff would be a lot more likely to jump from the present state to the future state. As the present state gets more unfavourable, staff will begin to move away from that state. But in addition to that it is also necessary to prepare the staff and culture for change by making the future state look a lot better than the present state. Are we going somewhere good? Is the future state more attractive than the present state?

Staff don’t need every tiny detail about the future state, but they do need a rough idea of where we’re going. They need to be able to visualise that there is a better place waiting for them out there and they need to be able to imagine themselves in that place.

This is where a change journey picture is useful, in summarising the beginning, middle and the end state. In other words by telling the corporate story. Storytelling translates dry and abstract numbers into compelling pictures of the corporate goals. Although good project business cases are reinforced through the use of numbers, they are typically approved on the basis of a story—that is, a narrative that links a set of events in some kind of causal sequence. An example of this is the attached slide used to communicate the current project I’m leading, which is part of the creative initiative to generate a new future, as opposed to conventional management approaches that search for virtual certainties anchored in the illusive security of yesterday. The change will affect over 3000 employees and change implemented across 17 sites across the country; all within six months time. A significant challenge indeed.  

Like all large programmes, and since the deployment of the Network Model, the Integrated Asset Management Information System (IAMIS) programme has been caught up in series of strategic review cycles over the past six months. This does not mean that the programme & project team has been sitting idle whilst the strategic direction is reaffirmed by the Corporate Board, but far from it; the team has been steadily progressing the development of the next phase of deployment in parallel. This was essential to maintain the programme momentum and retain the strategic advantage to move quickly into deployment when the green light has been given. 


Does this sound familiar in your programme?

Ok, I'm sure you have come across this scenario in your programme delivery (if not, trust me you will in your career as large scale delivery programme manager). You’re sitting in the monthly or quarterly programme review as a colleague plows through a two-inch-thick detailed programme plan (often summarised into few PowerPoint slide deck for the executives) for the investment in the next phase of IT deployment. When (s)he finishes, the room falls quiet. People look left, right, or down, waiting for someone else to open the discussion. No one wants to comment—at least not until the Senior Responsible Owner or CEO shows which way (s)he’s leaning.

Finally, the CEO or a senior executive breaks the silence. He/She asks a few mildly skeptical questions to show (s)he’s done his/her due diligence. But it’s clear that (s)he has made up his/her mind to back the programme/project. Before long, the other meeting attendees are chiming in dutifully, careful to keep their comments positive. Judging from the remarks, it appears that everyone in the room supports the programme/project.

But you know that such 'group hugging' prompts are often deceiving. Because the reality is, the head of a related division will often be worrying that the next IT deployment will take resources away from his/her operation or endanger other related/dependent projects (s)he may have in his/her agenda. Or others in the room are lukewarm because they don’t see how they stand to gain from the programme/project. But they keep their reservations to themselves, and the meeting breaks up inconclusively. Over the next few months, the programme/project is slowly strangled to point of death in a series of strategy, budget, and operational reviews. It’s not clear who’s responsible for placing the programme/project in a coma, but it’s plain that the true sentiment in the room was the opposite of the apparent consensus.


Yes, I've been there, so what should be done?

When establishing a new programme, programme managers have to accept that corporate decisions (or rather lack of it) might stifle the progress sometimes. It’s not about corporate centre seeking perfection in programme, but often its merely the assurance sought by executives about set priorities and disciplining the programme (and its team) to deliver them. The trick is, as a programme manager, to do well at the things that will move the programme forward, and for everything else, just don’t make any fatal mistakes.

However, this leads to a more macro-level challenge. As the programme manager, you’re defining your programme from the ground up. While my team and I have broadly applicable technology and approach, we have to accept that we can’t do everything, given specific resource and commercial constraints. Having limited resources is the common variable that binds all programmes/projects.

The biggest mistake that I see many inexperienced programme managers make is not clearly defining which opportunities they will target. This can be framed as a sort of Schrödinger’s cat experiment for programmes & projects. In the classic thought experiment, physicist Erwin Schrödinger supposed that a cat could be simultaneously alive and dead if its fate was dependent on the unobserved state of a quantum system. As programme managers, our number one driver is always achieving success for our programme/projects and keeping it alive. But a organisation's fate is dependent on an unknown: Which of the multitude of opportunities is the corporate objective delivery path? The decision is usually made with very limited information, leading to a highly uncertain outcome.

The natural psychological response to this dilemma that many corporate executives have is to simply not make a definitive choice — to run multiple options at the same time. But believing the cat is still alive somewhere in the flurry of activities is a fallacy. With limited resources, you risk running out of capital before achieving important proof points to keep the programme/project alive (especially applicable to Agile type project delivery).

The answer to this conundrum feels unnatural, but it involves making decisions quickly and resolutely with limited information. What’s often not obvious is that if you move fast, you have greater opportunity to recover from mistakes and try another option should the first choice not pan out. The ability to consistently make good, solid decisions lies at the heart of any programme/project initiative, especially those affecting entire organisation or operation.


How to speed up corporate decision making that supports your programme/project?

A culture of speed is required — rather than a piecemeal approach, the most effective strategic solution for increasing speed across the organisation is the development of a “culture of speed.” Just like any other type of corporate culture, a speed culture permeates every department and business process including recruitment, production, product development, finance, decision-making and logistics. In order to maintain speed in a speed culture, every new programme, project, idea, product, process, etc. must be evaluated for its positive or negative impact on corporate decision making speed.

Corporate decision making speed must be defined, measured, and rewarded — As the old adage goes 'what gets measured, gets done' - measurement is critical for improvement in corporate design making speed. The overall speed of an organisation can be measured based on how fast (in weeks) after it identifies a major change or problem in the environment that it successfully plans and invests in its response. Fast-moving organisations start by closely monitoring their environment and then rapidly responding to any new technologies, actions by their competitors, new laws/regulations, changes in economic factors, and changing customer and market forces. All speed related failures must be analysed in order to determine and then fix the factors that contributed to the reaction time. Obviously employees and managers that move fast and accurately must be both recognised and rewarded.

Innovation is closely related to speed — there has to be a reason for moving fast and one of the primary one is the need for innovation. Because innovation may have up to 10 times more economic impact than a focus on productivity and efficiency, the rate of innovation as well as the speed of innovation must be monitored and continually improved. This also applies to the innovation within the programme/project delivery for example, better way to manage configuration, collaborate, document management, governance etc. The speed of collaboration, between employees from different programme/project teams. is important and is an essential component of innovation. 

Fast executives are needed — some individuals act, react, think, and learn faster than others. Organisation needs to vigorously recruit those who can operate successfully in a fast environment, because unfortunately a single slow employee like “Homer Simpson” in an organisation's executive board can permanently reduce corporate speed. 

Fast programme managers are also needed — you must be a fast programme manager in order to manage fast programme/project team. Unfortunately, not all managers and leaders are adept at moving fast and at making fast and accurate decisions. The rare “fast manager” and leader does understand the process for increasing speed, and as a result they are usually familiar with the most effective programme/project tools and approaches for increasing speed in their processes and their team.  Clearly managers and leaders need to be selected based on their capability of moving fast.

Corporate learning speed is critical — in a fast-moving world, organisations must learn rapidly immediately after new knowledge and information appears. For example, 'Infrastructure Asset Management' is the new approach adopted by many construction companies worldwide, and yet others have spent years theorising without actually moving into execution even though it is widely accepted as the common sense and right corporate approach.

The speed of sharing is also important — once an organisation’s staff learn about new information or best practices, there must be a process to ensure that their information is rapidly shared throughout the organisation. Wikis, forums, and social media platforms can all be used to speed up best practice sharing. The time that it takes for the entire organisation to eventually learn about a new practice or solution should be measured to ensure that it is continually getting faster.

Technology is essential for speed — in today’s world, it is almost impossible to be global, low-cost, highly innovative, and fast without the extensive use of technology. Programme and project leaders must constantly search for new software and hardware that can enable both faster speed and more accessibility (to connect often dispersed project teams across the globe). Leaders must also assume when new technology or tools are implemented that each will eventually become obsolete. To avoid a reduction in speed, a process for finding a replacement before the obsolescent date must be included in the implementation plan.

The above are only some of the vast range of options available to corporate executives and programme/project managers to speed up corporate decision making. From the competitive standpoint, if you want to be an industry leader and remain highly profitable, your organisation must master corporate speed and become a “fast company.” And as an individual, you must also realise that, if you want to remain employable throughout your career, you have no choice but to continually improve your own capability for speed in programme/project delivery.

The D Day is here, the Go Live for our new Network Model. Okay perhaps not as dramatic as the actual D Day, nonetheless it is a battle to ensure successful system implementation whilst minimising business disruption. 

But first, what is this new Network Model that I mentioned?

The new Network Model

In simple terms, it is enhancement or an upgrade to the existing network model of Highways England’s motorway and all purpose trunk roads. The new model provides enhanced functionalities such as - true connected network, better diversion planning and event analysis, more accurate asset location referencing etc. Moreover, this deployment was particularly important as the new Network Model, in simple terms, forms the base layer or the foundation upon which other asset systems will be deployed upon later this year and next. 

So how did I ensure this deployment (and others like it) was delivered successfully?

Have a game plan

The first thing to note is that it is crucial to have a well-defined plan in advance. 

Here is an extract of checklist of things I had for go live:

• What are the exact steps that will need to be performed for any needed data migrations or server changes?
• How do we perform the deployment? (Make a checklist and give every team member a printed copy of it. Cross things off as you do them, noting who did them and what date and time they were done.)
• How to back up any dependent applications/systems and data pre-deployment?
• If something goes catastrophically wrong, what is the procedure to restore the original version or restart the deployment?
• How do one reach the IT or support/help departments of all involved parties?
• When do we reach our go/no-go point (i.e., the point when you either commit to finishing the deployment or start to roll back the changes), and what should the criteria be?
• What are the post-deployment triage priorities? (This one is especially important, because there will likely be a lot of "squeaky wheels" begging for grease, and one needs to know which ones to prioritise first.)
• How do we take things offline and bring them back online if needed?
• How do one contact customers / system user to let them know things are okay or not okay?

You'll notice a lot of these items are not about "how do we do this?" but "what do we do if something goes wrong?" There's a reason for that, i.e. Murphy’s Law, which is that things can and will go wrong, and the quality of a go live depends just as much on what went right as how one handles the things that went wrong.

Be prepared physically and emotionally

Before heading into the last stretch before a go live, everyone needs a lot of sleep and rest because when things go wrong, everyone has to work long hours to sort them out. A team of folks already at their breaking point will not work well together, will have a hard time executing the basics, and will fall down flat when challenges arise. For team members with spouses, kids, etc., will have to take extra effort and need to get them on board too. There is no way I could have accomplished what I did on any of my go live adventures if my partner was calling me constantly begging me to come home or laying on a thick guilt trip about not seeing the kids over bank holiday weekend (when we chose to deploy, because operationally it was the most feasible time for the business).

Being flexible with the programme/project team

The team will likely work long, hard hours during the go live. It doesn't help anyone if you are a hard on the team about things like getting to the office on time, shaving, dressing up, etc. unless those things are absolutely necessary (such as on customer or management meeting days). For the go live I often went through, I often worked late and through weekends. If I had forced myself to go into the office early in the morning, I would have been too tired to be effective for the entire day. Instead, I let myself get the extra sleep, and then only went into the office if it made sense. Also, if folks are stuck at the office late, do buy them dinner to keep their spirt up.

Hope for the best, prepare for the worst

Many large organisations, especially critical mission deployer like NASA, builds triple redundancy into projects because of the fact that things will go wrong, no matter how much you plan. Unless you are working for a big enterprise, you probably can't do that. I had a Development environment (we called the the ‘Model Office’, a Testing/QA/Staging environment or two, and a Production environment. The best thing we did for our latest go live was import the data from Production into our Testing environment few weeks in advance, which let us catch a lot of issues early and test our data migration with the most realistic data set we could.

Remember we are all on the same side

As the pressure mounts during the go live, things often get tense, especially if your programme or projects involve first or second tier software developers/suppliers. It is easy for folks to start snapping at and working against each other instead of with each other. Finger-pointing will not solve the issues. You absolutely must not allow the pressure, lack of sleep, or other issues interfere with how you work with your teammates. When you are through it all, you'll be glad you kept your cool.

Celebrate Success

And once everything is over and dust has settled, don’t forget to celebrate with your team, to not only recharge those expended energy but also to boost the morale in preparation for the next wave of deployment. 

First of the National solution (the Network Model) is being made ready for deployment. With design stage almost complete, we are moving into configuration solution testing stage. Once this is done, we will initiate the User Acceptance Testing (UAT). The UAT is final testing that will be performed when functional, system and regression testing is completed on the Network Model solution. The main purpose of UAT is to validate the software against the business requirements. This validation will be carried out by end users who are familiar with the business requirements.

As user acceptance testing is the last testing carried out before the software goes live, this will be the last chance for the staff to test the software and measure if it is fit for purpose.

Why plan to do UAT?

The reason why UAT is essential is because developers and functional testers are technical people who validate the software against the functional specifications. They interpret the requirements according to their knowledge and develop or test the software from a technical perspective. This means that whilst they recognise software solution as being complete (from functional specifications delivery), there could be some business requirements and processes which are not covered by the solution, either because the end users requirements were missed or misinterpreted. UAT plays an important role in validating if all the business requirements are fulfilled or not before releasing software for mass use. Use of live data and real use cases make UAT testing an important part of the release cycle.

Many businesses who suffered substantial losses due to post-release issues know the importance of successful UAT. The cost of fixing defects after release is many times greater than fixing it before its release.

What is my strategy for UAT deployment?

The first step is the setup of the UAT environment and planning the deployment.  Carrying out UAT on same environment used by functional test team will lead to real world use cases being overlooked. Also crucial testing activities like performance testing can’t be carried out on test environment with incomplete data set or test data. Hence separate production like environment is being setup for the UAT.

Once the UAT environment is separated from test environment we need to control the release cycle effectively. Uncontrolled release cycle may lead to different software versions on test and UAT environment. Valuable UAT time can be wasted by not testing software on latest version. Not to mention the time required for issue tracking on incorrect software version.

The other crucial element is the UAT planning itself. UAT should be planned with clear acceptance test plan in requirement analysis and design phase. In strategy planning, set of real world use cases should be identified for execution. It is very important to define test objectives for UAT testing as complete test execution for large application is not possible in UAT phase. Testing should be carried out by prioritizing critical business objectives first.

UAT is carried out at the end of the testing cycle. Delay in any of the previous stages of development and testing eat up UAT time. Improper test planning, in worst cases, leads to overlap between system testing and UAT. Hence I have had dedicated resource in the project team focus on the effective planning, review of the test scripts and creating the UAT environment.

During the UAT stage, it is also important to consider and control new business requirements as incidents or defects. Often ambiguities in requirements get caught in UAT stage, leading to project scope creep.

To make the most of available time and resource, I have led the project team to select UAT staff from various central, regional and supplier teams. We are conscious that even if these staff are well familiar with business needs, they will need appropriate training to ensure effective UAT are done.

Additional challenges will persists in terms of communication between remote development, testing and UAT team, hence the plan is to have these UAT done in purpose built ‘Model Office’, where the software developers, programmers, users, trainers etc, all are co-located. This approach helps overcome communication barriers and expedites testing process.

Overall, proper planning, communication, execution and motivated UAT team are the keys to successful user acceptance testing.  

Ok, over the past 6 months or so, I've been quite busy  on this large complex programme (hence the radio silence), but on the eve of the new year, I felt it necessary and appropriate to capture my thoughts and vision for upcoming year, in particular, the subject of 'harnessing the power of big data'.

It goes without saying that, effective infrastructure planning and investment decisions are made when all the relevant asset data available are taken into consideration. The best possible source for such data is a well-designed data warehouse. We are therefore investing in development of sophisticated data storage systems, where we can take advantage of both structured and unstructured asset data.

 

Over the course of 2016/17, the projects that I'm leading will set the core foundations upon which these asset systems will be based, for example, the project will deploy a new Network Model with enhanced ‘connected network’ capability. Increasingly, we are moving towards setting up of a ‘data lake’ design that serves as the central repository for the organisation's incoming asset data streams. In such architecture, subsets of asset data can be processed for analysis in the data warehouse with analytical tools efficiently and at lower costs.  

 

Over the same period, I intend for my teams to develop wider analytical tools, to complement our existing ‘Pavements Investment Tool’, such as analytical tool for structures assets. The objective is to help management take more informed business decisions by enabling asset data managers, predictive asset modellers and service providers analyse large volumes of data and translate these into knowledge and wisdom, by uncovering patterns, correlations, trends etc.

 

By end of the 2020, the aspiration is to leverage the advancement in digital technologies to transform the way we capture, store and use asset data, to be more cost effective, productive and practical in generating actionable insights.

The 1990s saw a dramatic increase in the number of people with the job title Project Manager as organisations addressed the problem of an ever changing world through ‘Managing by Projects’. Many organisations adopted the PRINCE2™ methodology as a means to gain some consistency of project management approach across their now swelling ranks of project managers.

With both an increasing need for Project Managers and an increasing number of people claiming to be Project Managers, many organisations like the Highways England based their recruitment and development strategies on certification of project management competence. So for example, huge investment was made in late 2004 (following Nicholls Report), in the establishment of appropriate project management capabilities in the Major Project Directorate. Having a PRINCE2™ Practitioner certificate became an indication of competence (even though it is only an indicator of knowledge).

However, experience has shown that successful implementation of a project management method requires more than just training project managers. A successful organisation requires processes, technology, policies and standards for project management - which also need to be integrated with other management systems for them to work effectively and efficiently.

In the absence of an organisation wide project infrastructure, project results depend entirely on the availability of certain high performing individuals. This does not necessarily provide the basis for long-term or consistent project performance. But, such infrastructure doesn't establish itself overnight. It may take several years; it may take a programme of change to institutionalise.

This is where my project ‘Establishment of Portfolio Control Framework (PCF)’, delivered last year, comes in. In a nutshell, it is the best practice approach adopted by the Highways England to deliver its Capital Maintenance and Renewals Portfolio of works worth circa £1.7bn annually. I developed this to 1) develop Highways England internal Portfolio & Programme Management capability; 2) allow Highways England to be an intelligent client; and 3) drives programme delivery efficiencies.

This significant change project was delivered by me within just 12 months.

So how does it work?

To summarise (see animation):

• First, the Highways England’s suppliers (or Service Providers - SPs) identify the work needs on the network.
• The internal Highways England teams then use Decision Support Tools and IAMIS system (two of other projects I’m delivering) and other information to check and challenge the work needs identified by the suppliers.
• The internal team then develops robust ‘Regional Programmes’ using the PCF guidance.
• Taking a ‘fence to fence’ approach for example, needs identified can be grouped into ‘Projects’, to drive efficiencies.
• The suppliers then develop detailed solutions for the needs identified and approved in the regional programme.
• These solutions are then taken through a ‘Scheme Appraisal’ process and through to construction.
• Where a scheme scores low in scheme appraisal process but where technical solution is sound and overall value of that project is value for money, the Regional Director can approve the project for delivery.
• In this way the overall process provide national control at each stage, whilst retaining local flexibility, reduced bureaucracy and generates efficiencies.

The objectives of any effective maintenance management and customer enquires system is to transform operational performance and customer service through deep insight, total visibility and predictive intelligence that turn analytics-led insights into positive action for improved customer experience. That is the expectations I have, in leading the Integrated Asset Management Information System (IAMIS) project.

The current Maintenance Management module within IAMIS provides Highways England (HE) the capability to record defects, inspections, works order etc on a map based interface. Built on a COTS product, the module supports HE to maximise productivity and asset uptime, optimise inventory, minimise costs and assure standards compliance.

Complementing the Maintenance Management, is the Customers Enquires Manager (CEM) module. The CEM contains all customer contacts - enquiries, compliments, incidents, other correspondence, including Highways England Information Line enquires. This capability automates the process of creating, organising, tracking requests into a seamless process. The objective has been to provide exceptional customer service through better collaboration and teamwork through the system. It's not just a ticketing system. It's a complete customer support suite that simplifies communication and collaboration between HE internal team members, other users within the business, and HE customers.

The third element, is the reporting function. It is an application that allows real-time access to essential data as well as the rapid generation of multidimensional reports from diverse data sources.

Together, these three modules (along with others which I’ll cover in separate blog posts), provide formidable asset management capabilities for the Highways England.

 

The other significant element of the IAMIS delivery is the Asset Visualisation Information System (AVIS). In a nutshell, it is the interactive system that allows users to easily access and utilise wealth of data/information captured through on-road LiDAR surveys and High Definition videos.

What is LiDAR and how is it being used by Highways England?

The LiDAR is a remote sensing technology that measures distance by illuminating a target with a laser and analyzing the reflected light. LiDAR is popularly used as a technology to make high-resolution maps, with applications in geomatics, archaeology, geography, geology, geomorphology, seismology, forestry, etc. And in this case, Road inventory and (soon) condition surveys and data capture. Vehicle mounted scanners are used and are driven around the network at traffic speeds.

High Definition Images

Along with the LiDAR, at Highways England we are also capturing High Definition (HD) images of our network assets. This is being done to improve the quality and coverage of asset information. Using new techniques, in the last 12 months, we have established 92% coverage of on surface asset types (comprising of 62 categories) in 37 terabytes of cloud point data. The accuracy of Geo-Spatial referencing is now at 10mm relative and 30mm absolute and the accuracy of inventory referencing is at 99% accurate. These performance levels is world class leading and exceeds other infrastructure asset operator.

With advances in road survey technologies and visualisation, AVIS provides the Highways England with advanced capabilities, with accurate 3D representation of the network assets; interactive tools to allow users to carry out basic road assessments from comfort and safety of the office; and huge savings compared to traditional methods of onsite surveys and assessments.

This system has been deployed in the business and is operational.

What is IAMIS?

This is one of the number of projects / programmes that I'm currently leading for the Highways England. The IAMIS programme is an ICT enabled business change programme.

But before we explore IAMIS, it is important to understand a bit about the Highways England (HE). The HE (previously a Government agency and now a company) manages one of the largest infrastructure assest in England, worth in excess of £119 billion. This means that it owns and operates wide ranging, complex physical assets, such as roads, bridges, drainage, traffic technology, lighting etc. As a result, HE is a 'data rich' organisation with terra bytes after terra bytes of data about its assets.

So what is the issue?

Given the extensive nature of the data, HE faces a significant problem in manage the data, due to:

• varied legacy asset systems
• none of these systems talks to each other
• data contained in them are duplicated, inconsistent, missing etc

So the solution I'm delivering is IAMIS.

Do visit my blog often and find out more information on this and many other fascinating projects.