So I’m one of the project guys at ITQ.
I’ve taken on a fair share of infrastructure projects over the last decade with great diversity: implementing new network topologies, configuring hypervisors, developing new software, upgrading operating systems and applications.
Now. Projects can be difficult for many reasons, the project methods are less complicated. Call it PRINCE2, IPMA or any other project method, it always boils down to this: you have a set of activities which have to be completed given a certain amount of time and budget. You break down the activities into a logic and cohesive order and get started, meanwhile informing the stakeholders, guarding project tolerances, managing your project team and updating the project documentation. I know, it’s a simplified version of reality, but in essence, it’s like this. And. I love the results: it’s always satisfying to create, upgrade or add new features to existing IT environments or even create new ones, especially if solutions are technological advanced.
But. Last few years in particular, these technical solutions have been so fast paced and so highly advanced, administrators and end users need additional skills and a different mindset to work with them. Furthermore, IT moves towards the business, resulting in new business insights and opportunities, but critical questions as well. Managers and end users nowadays have more control over IT resources while requesting shorter implementing times. More processes need to be automated. These developments require a different type of administrator, but also a different approach by end users.
Sure, you can add a training program to your project, but sometimes (and more so) this doesn’t cut it. What if an apparent IT infra project results in process changes for the IT department and/or the business? Or even adjusted job descriptions? Or cutbacks in FTE’s?
Let me give you some examples.
We recently implemented VMware vRA for a client. Its main purpose was to provide developers with a self service portal where they can order and manage their (temporary) development environments. The project was a success from an IT point of view: we created a beautiful portal with the functionality requested. The developers where made responsible for maintaining the software images (including standardizing their tools). However, no time was claimed for this and nobody felt responsible. They had to get used to the portal and they had to change their developing methods as well, agreeing to a standardized method of programming. The portal is still running, but it’s rarely used by a developer.
The same goes for security guidelines. Nowadays, everybody wants to access their data anywhere, anytime and from any device. Many projects are all about BYOD, virtual workspaces, etc, penetrating the big ol’ fence most companies put around their network over the past decades. IT departments still live by these old guidelines, but the requirements of the business defy them on any given day. It requires an adjusted method of working and handle security from a different point of view: it’s a mix of new skills and a different mindset.
Of course, you can inform the HR department changes are about to happen and you rely on line managers to motivate their people. But oftentimes, they learn about a project after it’s completed. Sounds familiar?
Hey project guy, are you saying project managers should become HR-experts? No, I’m just saying people and processes are often influenced by the outcome of IT projects, but these consequences are not always identified. What if an IT project should consider these sides as well and encompass them as project deliverables? It would have a positive impact on ‘people acceptance’ to use the new infrastructure. What if you can advise project board members at the start of the project these areas deserve focus as well if they want the project to be a success? It would be an added value as a project manager to be able to discuss this with the project executive, I think.
That’s why me and my colleagues have been attending the TIAS Masterclass “Change Management”. We want to give clients and project executives a solid advice on the ‘soft’ sides of IT projects: how will a project affect processes and people? Can/should we address these aspects so the project will not only be a technical success? Sure, we can complete a project within budget and time, but what if the results don’t blend in with the processes? Or what If people don’t want to work with the new technology? Or can’t?
To me, Change Management is a perfect add on to my project management skills: all projects are changes to begin with anyway. But. Change Management is focussing on the human side of it. Resistance, blind spots and the dragging “this is just how we do this”: it’s behaviour you encounter in many organizations and failure or success of a project can depend on dealing with it.
I’m not pretending to be a heavy-duty Change Manager after this masterclass, but at least I can work with and talk to experts who are. I do dare to act as Change Manager in relative easy situations: the masterclass was extensive and we have been given a lot of hands on tools and methods. We now know what aspects are involved and we can make an initial estimation whether a project should have a focus on change management. We can inform the stakeholders, so they can make informed decisions.
To me, a project is truly successful if people want to use the new infrastructure, are aware of its benefits and are capable of using it. I believe Change Management can be an important aspect to achieve this and at least a consideration in many IT projects.