Shôn Ellerton, April 26, 2017
If your project is making no headway in getting your corporate IT to implement a tracking solution for your project, why not try putting something in place with little or no corporate IT involvement?

The Problem

In my experience, most projects start by tracking their progress and storing their information in spreadsheets, but as we all know, once the project grows, using spreadsheets quickly becomes unwieldy and becomes subject to problems with data integrity, security, size and accessibility. It's a common problem that is not always easy to solve. And, yes, I will be 'taking a dig at' Corporate IT from my own experiences, albeit, in a constructive way.

Planning and setting up your project-tracking system during the inception or very early stages of the project is great, but as we all know, hindsight is a wonderful teacher! It is usually at the stage when the existing spreadsheet-driven system begins to fail is when the Project Manager (or who ever makes the decisions on what systems to use for your project), will request the services of corporate IT for advice.

First off, ask if there is anything available within the organisation that can be used. If there is, this can save a lot of pain and frustration as, undoubtedly, whatever has already been implemented will (or should) be fully maintained and supported by Corporate IT. If not, then a new solution may be required and at this relatively late stage of the project, this solution will probably need to be delivered as soon as possible without exceeding budgetary constraints.

The typical request that many project managers would put forward could be something like the following:

'We're drowning in spreadsheets. We've got copies floating all over the place and nobody's updating anything or they can't get access to them. Can you come up with a database or something like a cut-down version of a system that project team are using over there?'

I know it sounds a little stereotypical, but it's true, I've heard it over and over again.

The response the project manager obviously wants to hear is:

'Sure. We can take all your spreadsheets and chuck them all into a database. We'll give you a nice reporting tool along with a snazzy user interface. How does next week sound?'

This is, of course, highly unrealistic.

The reality is that Corporate IT will more likely respond with one or more of the below solutions:

'If you submit a requirements brief, we will scope out what is needed to fulfil your project's tracking requirements.'
'We can offer support for your project by providing server space in our network in which you may install software (e.g. database, BI platform, etc) for whatever you need for your project. The project; however, will be responsible for all additional software licencing costs and all development.'
'We already have a system in place which may be suitable for your project. We can set you up with an account in our sandbox area to test its suitability. If the system proves unsuitable in its existing guise, please submit a scope of requirements which we can then review to assess how we can 'tweak' the existing system to accommodate your project's requirements.'
'We are discouraging the creation of new systems on the corporate network in favour of a new corporate-wide work management system which, once completed and rolled out, all projects will be able to use.'
'We don't have much in the way of infrastructure or resources to support your project; however, we are more than happy in offering assistance in selecting and setting up third-party cloud-based products for use on your project.'

Five solutions; five conundrums. Let's just take a moment or two to reflect what that problem was again but in layman's terms.

'Our project has outgrown its existing system of using spreadsheets and, damn it, we need something done about it really quick!'

Now before I start dissecting into the details of the five solutions above, I want to take you into the differing mindsets of Project and Corporate IT.

Projects and Corporate IT Mindsets

Put bluntly, from Project's perspective, Corporate IT do not seem to possess a sense of urgency being riddled with bureaucratic processes seemingly intent on making the simplest into the most complicated. From Corporate IT's perspective, Projects don't understand the level of work required to create a system which is intuitive and easy to use and often find deadlines set by Projects to be unrealistic.

Let's look at this in further detail.

As we all know, when Projects fail to deliver services or products to their clients, it is unlikely that they will succeed in winning business again from these same clients. These clients will look elsewhere if possible, which means, of course, that they will no longer be pumping more revenue into the business.

We also know that the client is the boss and has the right and power to 'move things around' at very short notice provided they do not violate any conditions of the signed contract. In every signed contract I have ever read, the systems area (e.g. reporting, data exchange) tends to be extremely woolly and vague open to a great deal of latitude by the client. Why? Systems experts are usually never invited to review the contract before signing. After reading some of these signed contracts, I can loosely translate the small print in to something akin to

'the client has all God-given rights to request all your project's data, and, by the way, just because you are the vendor, it doesn't mean you can access the client's data and did we fail to mention that the client can change their systems at the drop of a hat?'.

This means that your own systems need to adapt very quickly to the client's needs. The means of implementing or changing your system to adapt must be quick and flexible and must not be impeded by lengthy and bureaucratic processes within your internal organisation.

I may be harsh in saying this, but what Corporate IT tend to collectively forget is that Projects are at the 'coalface' responsible for bringing in revenue to the organisation's coffers. Corporate IT usually rely on the organisation's projects to service their revenue streams via an agreed pricing structure. Common examples I've come across include either a percentage of the project's worth or through a month-by-month review of IT services rendered through a CAB (change advisory board) of which a SoW (scope of work) is submitted by Corporate IT to the Projects.

Let's talk about timeframes. Clients want results delivered to them at an agreed timeframe. If you don't, there are obvious detrimental repercussions. Again, I have to be brutal in saying this, but in most cases, Corporate IT just do not seem to share the same sense of urgency that Projects has with respect to delivering a product. Let me be clear, I am referring to Corporate IT collectively, not the individual programmers, analysts, desktop support staff and other IT staff at the working face who often experience intense pressure through their own management.

On the other side of the coin, Projects tend to have an oversimplistic view of what is required to implement and maintain a successful project tracking system and often regard the 'perfect' system to be the panacea for bad project management.

Here are a couple of classic phrases directed towards IT often heard repeatedly:

'Can't we just throw in another column in the report?'

'Surely we can just add an extra milestone?'

'Can we have a dashboard?'

And the mother of all mothers!

'Why can't all our systems speak to each other?'

After all, it's far easier to blame the system implemented by somebody else rather than poor management practice.

Thankfully, there are a few of us out there who can bridge the gap between Projects and Corporate IT.

Let's now run through decoding what the five solutions in the previous section mean.

Five Solutions Decoded

Remember, as mentioned above in the first section, if something already exists in your organisation which fits your requirements, then use it. If not, here is a breakdown of five typical solutions given by Corporate IT.

1 - The BAU Solution (Business as Usual)

'If you submit a requirements brief, we will scope out what is needed to fulfil your project's tracking requirements.'

I would say that this would be the most common (and in most cases, correct) solution. Unless you have an in-project business analyst, you will somehow need to transfer enough knowledge about your project to someone else on the outside. For example, if you were to request a program to be written for smartphone use to assist in providing and validating pre-flight checks for your company's fleet of new helicopters, simply giving a list of checks on a piece of paper without much further explanation is simply not going to cut it.

Writing a requirements brief can be daunting and unfamiliar for those based in Projects. First thing to do is to ask what the timeframe is between submitting your requirements brief and getting a response. Corporate IT should include a rough estimation of cost and time required. If your project or corporate IT has a business analyst on tap, the easiest way is to have one or more sessions in person detailing what is required and then get the business analyst to submit your requirements brief on your behalf. If no business analyst is available, then your corporate IT should provide you with a template for you to complete and submit. If possible, request an already-completed template which you can use as an example.

Depending on the outcome of the brief submitted, the Project will need to decide whether to go-ahead or not.

2 - The Flexible Solution

'We can offer support for your project by providing server space in our network in which you may install software (e.g. database, BI platform, etc) for whatever you need for your project. The project; however, will be responsible for all additional software licencing costs and all development.'

Rarely found these days in larger organisations, this is not to dissimilar to a 'self-service' system in which the Project is given unhindered access to internal network resources to deploy and maintain software. This may include running an instance of a SQL Server database, a website platform, business reporting software, scheduling software and so on. Hybrid solutions sometimes exist in which Projects might have access to a shared resource, for example, ownership of a database on a shared instance within a shared box.

However, this solution is usually deeply unpopular within Corporate IT circles often claiming that performance, reliability and security is heavily compromised when accessed by non-IT personnel. From a 'broad-brush' perspective, there is an element of truth about this; however, management within Corporate IT often dismiss the notion that there could actually be Projects staff that have far better experience in efficiently putting a system in place given the tools to do so. This seemingly open air of arrogance can sometimes drive a divisive wedge between Projects and Corporate IT, especially during times when Projects are floundering due to the lack of a project tracking tool.

Synergy between Projects and Corporate IT can often be achieved by familiarising appropriate personnel working on the project with the processes and guidelines set by Corporate IT. By the way, I despise the word 'champions' used in the corporate context and refuse to ever use it as such. A compromise can be met whereby the Project has unfettered access to a development version of the system in which Corporate IT can then push to the production environment. This provides Corporate IT with a chance to monitor any changes which may adversely affect the production environment along with the added benefit of limiting production access to a limited few.

This option only works if, of course, you have someone within Projects who is technically able to put a system in place. If the system requires a complex (n-tier)web-driven application, this option is probably not suitable. However, saying that, I have seen a staggering array of powerful Wordpress themes and add-ons which can service complex database-driven websites with very little effort. No doubt the same will apply for Drupal and Joomla. In most cases, all that is usually required for many small to medium-sized projects is a database where data from spreadsheets can be migrated into coupled with a simple client application to update and retrieve the data. It is worth scouting around within your project team if there is sufficient expertise to build and adminster a system. If not, it could work out cheaper to hire someone with these skills to join the project directly rather than shelling out on Corporate IT services to undertake development.

Corporate IT may not allow this solution in any shape or format. When this happens, Projects have the inate ability to react accordingly. I've seen Projects develop quite capable mini-systems driven by a local Access or cloud-based database only to grow in size and complexity. It's interesting that only when they reach a certain level of 'stardom' that Corporate IT seem to take notice, at which point, of course, it is usually too late for them to take control. Corporate IT should wisen up to the fact that Projects with technical experience in system-building are not going to sit around with their hands on their backsides fumbling around with spreadsheets if they can find a better way.

3 - The Green Solution (Recycling)

'We already have a system in place which may be suitable for your project. We can set you up with an account in our sandbox area to test its suitability. If the system proves unsuitable in its existing guise, please submit a scope of requirements which we can then review to assess how we can 'tweak' the existing system to accommodate your project's requirements.'

Towards the beginning of the article, I mentioned that the first question to ask Corporate IT is if there is an existing system which could be used to service your project. This solution is the next best thing because if there is, indeed, a system which could be altered or tweaked to suit your project's requirements, then you should take advantage of it. However, if this requires extensive tweaking, then you might want to rethink this option before embarking on it.

4 - The Autocratic Solution

'We are discouraging the creation of new systems on the corporate network in favour of a new corporate-wide work management system which, once completed and rolled out, all projects will be able to use.'

This is a solution that should send alarm bells ringing to your ears. In one of my earlier articles, Do You Really Need That Expensive Online Work Management System, I discussed the high risk of rolling out corporate-wide 'all singing and all dancing' one-for-all work management systems (WMS). Rolling out successful corporate-wide work management systems is a major undertaking and involves extensive continual interaction between Projects and Corporate IT through its lifecycle. If you get this response, ask if you can get a demonstration of how it works and do some testing with your project in mind. You also need to ask for a concrete date when the WMS will be formally released. If these are unanswered or not forthcoming, it is clearly too early to even comprehend going down this path. At this stage of the game, it is 'vapourware' as far as you are concerned and you should explore other options.

5 - The Modern Solution

'We don't have much in the way of infrastructure or resources to support your project; however, we are more than happy in offering assistance in selecting and setting up third-party cloud-based products for use on your project.'

I think this is a great solution in most cases and I see this becoming ever more popular as corporations realise they can economise by reducing spend on their Corporate IT departments. Many organisations are already hosting email and other user services via cloud-based services. Some organisations are hosting all their software through cloud-based services from databases to scheduling software. Corporate IT management often view using cloud-based services as a viable solution enabling Corporate IT to dispense with expensive infrastructure upkeep, backup control, resilience and hardware updates. The core function of Corporate IT will still remain with respect to desktop support, computer asset control, core software and other peripherals including printers, phones and tablets. However, with respect to software services, they are, in fact, acting as the gatekeepers between the cloud and the Projects.

What Corporate IT may not envisage; however, is that this option is also open directly to the Projects. Unless the organisation takes on the 'big government' mentality and sets a draconian policy, or worse, block IP services to prevent Projects from subscribing to a cloud service, there is really nothing to stop your Project from subscribing to a cloud service. All you then need is to have one or two people who have technical experience working directly for the Project to deliver what you require with the added bonus in that they also have a thorough understanding of the Project.

Should Corporate IT offer assistance (if even required) to set up cloud services for the project, it will, of course, be conditional that the Projects are fully responsible for the system once implemented.

In either way, it is a win-win situation. Corporate IT have reduced their overheads and Projects have full control of their system.

Conclusion

As you may have guessed, there is never only one solution; however, I am particularly excited about the increasing use of cloud services directly by the Projects as highlighted in the fifth solution above. Third-party cloud providers are very competitive in pricing. Their infrastructure is generally more reliable, resilient and up-to-date than infrastructure owned by most organisations. They are easy to use. For example, you can set up the base infrastructure you need with a few clicks of the mouse with Amazon Web Services (AWS)*, although there are plenty of other providers to choose from. Moreover, a host of other features are usually available including data sovereignty (where the data physically resides), backup management, auditing and full control of how secure you need the services.

* As of writing, there was a reported incident early in March 2017 of unplanned disruption to Amazon Web Services as reported by Reuters; however, please consider that a much higher number of (usually) unreported disruptions occurs on company infrastructure.

But We Need Something to Track Our Project Now…!

The Problem

Projects and Corporate IT Mindsets

Five Solutions Decoded

Conclusion