Clarity is all important

One of the recurring needs in my work is to bring clarity. What is it we are doing, when are we doing it and who is doing it?

It seems so obvious that clarity is needed but it is so often overlooked. And the clarity needs to be clearly communicated too – in other words it is not just clarity of thought but clarity of communication that is needed to. Without this, chaos can – and very often does – ensue. That is an expense hole to dig yourself out of. And projects do fail when chose has the upper hand.

The temptation to create complex structures is driven by complex needs and situations. I understand that but somehow project managers need to be able to break that complexity into bite sized chunks, chunks that can be easily understood, both in splendid isolation and when placed in context with everything else.

Clarity is good and it helps to keep projects on track. I can recommend it!

It’s the basics that catch you out

So I have had a busy time of late, including being dropped in to understand what a few projects have needed to be made good. And, in doing so, to understand what might have gone wrong. 

For a change, technology is not the fault. It’s the PM basics of defining a scope and then managing changes against it, which is forgotten. This leads to all sorts of unhappiness and executive disquiet. Heavy stuff to listen to and deal with. 

Similarly poor communication and expectation management will result in some very unhappy people. Clear communication on progress, the expected outcomes, alongside the clearly defined scope, is essential. This is so that everyone knows what your team is doing, when, where and for who. 

This applies to all projects whether they are in or out of the Cloud. And it’s hard because project sponsors and your executives alike will want more, faster and for less cost. It’s where my favourite word “no” has to deployed. Not to be awkward or belligerent but to defend the project and it’s successful outcome. Every request from your baseline has to be refused – unless a defined change request is agreed reflecting the change to the cost and timeline. 

And whilst I am in “gripe” mode, using agile methodologies is fine but it has to be done properly with control – it is not an excuse to have a plan as a blank piece of paper, making it up as you go along. Project failure leads in that direction. I have seen it. Customers are attracted to the idea as they see as an opportunity for getting more than they pay for. Usually, the words “agile” and “discipline” are not accepted in the same sentence – but they have to be. 

Really this all comes from the Project Mangement Department of The Bleeding Obvious. Yet I encounter it again and again. It costs to fix – much better start as you mean to go on; or as someone like me has to painfully introduce mid-project. 

Again and again the causes of project failure are ignored in project execution. And yet these causes rarely change. Mistakes are there to be learned from, other people’s as well as your own. Stick to the plan people!

Cloud and non-Cloud Project Management

I was recently asked what makes Cloud project management different from nomal project management. And the answer I gave was perhaps surprising – in project management terms, they are the same. 

When I first moved into managing Cloud Projects, their was a mystique about them. The challenge of getting to grips wih the new project management constraints I took to be a challenge – if slightly daunting – of relearning project management. After all, this was a New technology with new philosophies to be observed. It had to be different, right?

But what I soon discovered was that you still needed a plan, some resources and to manage the holy trio of risks, issues and changes. 

What I did find is that there is a layer on top of this, a need to understand – and be focused on:

1. the business case
2. improving the overall processes being transformed to one as efficient and as automated as possible. 

This is where project managers in the cloud earn their keep, providing business and process expertise. Very often I find clients appreciate the experience gained elsewhere to further their journey into the Cloud. 

So for me, this added X factor is what makes Cloud projects interesting. But at the end of the day I use normal project management techniques. Putting the two together is (usually) fun. 

Cloud projects are not just about the technology

A recent client engagement was starkly revealing. For once, the technology was behaving itself but at a meeting of stakeholders, it became apparent that the organisation was not yet ready to use the new system. And that the stakeholders present were not the real stakeholders. 

For cloud to give pay back, it should really be part of transforming the enterprise in some way. Done right, the enterprise has an opportunity to use the speed and flexibility of the new cloud to do things in a new way. A new way that speeds time to market, brings new agility, real benefit. 

And so the technology project is important but it has to be part of a wider change programme. For example, who needs training, who has the opportunity to do something different, who has the chance to deliver value in a new way? This needs careful analysis and thought with a well crafted programme that transitions from the old to the new. This is never painless – but done right is worth it. 

Just focusing on the technology is a mistake. Place it in the centre of a wider programme of change is the only way to get that sought after return on investment. 

Half automation and half manual is bonkers

Implementing cloud technology is not cheap. It takes time, money and effort to implement a cloud solution, requiring a great deal of commitment and vision to realise financial and organisational benefits.

So I was aghast to work with a client recently which is spending a lot of money to introduce a cloud automation solution involving the integration of a few major systems, only to discover that at the heart of the creation process for virtual assets is totally manual.

I will say that again, the heart of the solution is totally manual.

The impact of which is that the capacity for the system to create the required virtual assets is limited not by the the processing power, the storage availability or other system constraints, but by the availability of people to create the virtual assets and the time those people are available.

Plainly, this is bonkers.

Without giving too much away, it seems to me that the vision that is driving this new system is flawed and is focussed not on realising the maximum benefit, but on creating a beautifully complex operation. All that is being achieved is that the management of the manual work is being automated – nothing else. The organisation will not realise any benefits from the agility and flexibility that Cloud can bring.

To my mind, the business case does not go far enough and the vision driving the new system forward is out of focus and, at best, blinkered. And with the considerable manual effort involved, there is a very real risk of inconsistencies being introduced into the provisioned systems, which give rise to compliance risks.

Had I been involved when the initial macro design was being done, I would have recommended:

1. going for the maximum automation to provide a fast and agile service to the target users
2. do not automate – or partially automate – the existing processes but be bold and think out of the box
3. be totally focussed on the benefits to be obtained and be single minded in pursuing them.

The customer is always right of course and so we have done what they want. But it is not a comfortable position to be in to suggest that their desired course of action is unnecessarily expensive and not the best way to do it. And that a better way is to do something different.

Ouch.

And bonkers

Keeping a Vision Alive

Cloud projects are no different from any other project, in that it is imperative to have a system vision aligned with a business vision – together they should give clear and measurable benefits to the enterprise. But as several major projects have found, keeping that vision alive over a multi year project is tough and keeping that vision aligned with changing circumstances is even tougher.

Every project as it progresses discovers things about itself, the system objectives and the business vision. Sometimes those discoveries can be difficult to accept as they challenge (potentially) some of the pillars that built and justified the project in the first place. It is not unheard off to hear about projects that justify themselves out of existence.

And this is where pride can be obstacle. The proportion of projects that fight on to the bitter end because an organisation has no courage to either admit:

• it is not needed anymore due to a change in environment, circumstances, etc
• or a better idea has occurred to someone, that changes the project vision in some way.

Every project starts because someone has a good idea, something that not only helps the enterprise but helps to show that individual in a positive light. And why not? We all have to continually justify our existence to our employers. But some people lack the courage to accept that someone else has a view that changes their own vision and ideas, even though they are committing their enterprise to considerable expenditure in the meantime. My experience suggests that this courage is prized by most organisations.

The move to Cloud Computing is about becoming more agile as an organisation, doing “things” more quickly. If a Cloud project is taking more than a year, then I think that is too long – you cannot be agile in a multi-year way. It might be better to pause the project and break down the vision into smaller, more manageable chunks, that allow more reality checks on the vision to be taken at each break point. Having the courage to change direction means the resultant Cloud system:

• is aligned to the Enterprise as it changes in an agile way
• delivers benefit incrementally earlier to the enterprise.

And this where strong and fearless governance is essential.

It can be hard to say “you know what, I think we should do something different now”. With the agility that Cloud Computing brings, it is really necessary to introduce agility of thought and vision.  Building that into project delivery might be hard – but is absolutely essential.

Cloud automation and the support organisation

I was at a friends house having dinner recently. 

One of my fellow guests was a guy who had worked in the banking industry, back in the mid-sixties. In those days, all of the branch records had to be written up by hand, which meant the doors closed at 3pm to enable the transactions of the day to be recorded.  There was no automation in sight and calculation machines were used only to double check mental arithmetic. Roving teams of inspectors would turn up at the branch unannounced as the doors closed, would conduct rapid forensic analysis on the books to find error and fraud – and woe betide anyone who found themselves the culprit behind anything that was discovered. 

In those days, I guess the skills of bank staff were slewed in this direction, people who could do manual book keeping and checking – and who could do it fast and well. Of course as the sixties closed out, the banks did then begin to engage in the deployment of IT, enabling automated processing and record keeping. Fast forward to today and whilst there is a lot of bank staff still engaged in customer service, they each service a higher number of customers than would have been humanly possible in the manual sixties. The cost of servicing each customer has been reduced and new services can now be offered that were simply not possible in the manual world . 

Of course it has not been a free ride and banks have had to engage a lot of IT support and development staff, never mind the physical hardware, to do all of this. The banks got the automation story, that software investment enables costs to be reduced, but also opens up many new possibilities. But they needed to ove to a different skill mix in their organisation to make this transformation possible. 

I was with a client recently who realised that the new cloud system they were about to start using, was no longer about people manually installing infrastructure. Using the automation features of the cloud enables systems to be created, amended and deleted at the request of a button on a screen. The client realised that from this point on, the support of their virtual infrastructure was now (mostly) about software development, which means their support team will need new skills and approaches. 

No longer was the provision and maintenance of compute power just about manual tasks. Instead it was to now about software development.

They would now need a different mind set to get the maximum out of their virtual infrastructure and fully reap the benefits of automation in the process. I observed to the client that they were at the same point as the banks in the sixties, where a different skill mix is required to enable the enterprise to to do more than it can today. It was spooky that the next day, I was having dinner with someone who was in a bank in the manual sixties. 

Implementing a cloud system helps with problems enterprises face today. But – and this is the most interesting thing – it opens up a world of possibilities for tomorrow. The parallels between where this client is at and my fellow dinner guest from the bank in the sixties, seems compelling to me. 

It also highlights that implementing a Cloud system is far more than just installing new hardware and software. It goes deeper into the enterprise, providing opportunities to rethink how things are done today. And enterprises need to embrace the impacts on the skills needed to support the compute power in this new world and that new ways of thinking are needed to do this. But this transformation enables huge transformational opportunities for the enterprise. 

It was interesting hearing first hand how banking was done in the sixties. But I cannot imagine there are many people who would wish to go back to that manual time, either as a worker or customer. Clients embracing Cloud technology rarely look back either – but only if they challenge themselves to really transform.

Moving to public clouds – what then?

The opportunities to buy services from a public cloud seem to increase daily. The flexibility it brings and the knowledge that someone else looks after the hardware, makes the public cloud an attractive option.

But a conversation with a client and colleague recently indicate to me that “lifting and shifting” processing to public clouds, what I call “credit card clouds”, is fine as far as it goes. But there is a further step to go, which requires some experience and guidance – that of using the cloud to transform the way the business runs.

Back in my early IT training, I was taught that “rubbish in = rubbish out”. And this also applies to moving processing into the cloud – public or private. Yes there are some benefits to do that but to realise the full potential, something extra is needed. Such as looking at the way the system is built – can it be done better, can it be built simpler, can it be more maintainable, can more standardisation be introduced? Can things be set up to enable business users to access compute power when it is needed, to fully spread the cloud flexibility through the organisation?

This is where some serious leadership and experience is needed to take enterprises on this next stage in their cloud journey. For enterprises that need to know they are running as lean as possible, that need to know they are realising the full potential of all of their assets, then this is a vital step to take. Only then will Cloud Computing give its full value to the enterprise, even when using a public cloud provider.

Wot no governance?

I am involved with a client just now which is experiencing growing pains with its brand new shiny cloud. Needless to say I cannot go into details here about what is going. But shortly they are to upgrade a key piece of middleware which is shared by this cloud and other systems. And that the decision has not considered the effect on the cloud system, even though it will probably break it.

Now those discussions with the senior management have not concluded and this may all get fixed to everyones satisfaction. But thinking about this today,  I realised that the Cloud Governance is not there. And that is a fail.

Cloud systems are complicated beasts which take investment and time to get installed. And once there, the enterprise need to get value out of the system, and check that the ROI is being made. But to do this, it needs to work and Governance has a key role to play in making sure that happens.

So if your enterprise uses Cloud, just ask yourself if the governance is there and effective. If the answer is “no”, then your enterprise cannot assure itself that the ROI is there.

Timbo’s Cloud Rules – now on Slideshare

Last year I published this post which contained ten rules to aim for in building a cloud. It was also published on IBM’s “Thoughts on Cloud” blog, where it ranked as the #7 post in 2013.

This year I have produced a slide version and shared on Slideshare, where it can be viewed.