Get more insight from HSO
Dynamics Matters Podcast Ep 68: The role of an enterprise architect for project success
With special guest Jacqui Hoyle, Enterprise Architect, HSO.
✔ What is enterprise architecture?
✔ What role does an enterprise architect play in a project?
✔ The risk of scope creep without enterprise architecture
Welcome to episode 68 of the HSO Dynamics matters podcast.
Your regular sonic dive into the world of Microsoft technology related matters and much more besides.
I’m your host Michael Lonnon, and in this episode, I tiptoed into the highly specialist world of Enterprise Architecture. Something I confess to know only a little about.
But after spending 10 minutes chatting with HSO Enterprise Architect Jacqui Hoyle, I learned more about the subject as well as why it plays an important role in project success.
So, grab a brew, sit back, relax, and enjoy the show.
People before processes or processes before people?
People before processes.
What do you think is generally the most important factor in a project? Is it the technology that goes in or the processes that are setup or is it the people coming up with the ideas?
The most important thing is the people engagement, getting them to understand and manage expectations so they’re on the same journey. If they’re on the same journey, then you get success and you get results. If you’re fighting in a different direction, it doesn’t work but to layer that in with clearly defined scope follows people and process because it all fits together. So, everyone knows what we’re trying to achieve.
As an enterprise architect, you’re knee deep in the detail and in the project and I guess it’s quite tough, almost a juggling act when you’ve got people from different organisations. You’ve got the customer that wants the solution, you’ve got us as the partner, you’ve got the vendor, as in Microsoft, and you may have other partners, with other technologies. How do you juggle and manage expectations in the journey that you talked about?
It’s still about framework and structure. We have a what we call an EA plan, which clearly defines what the customer is going to achieve or expect from any engagement. That starts from the strategy session, which is why we do this, why we are sat around this table, what we’re trying to achieve, what’s the aim? What’s your objectives? So, it starts from the very top and after that is different layers of application architecture. So what systems are in play, and then different layers of the functional side. So, what can we do from a functional perspective to engage with the processes and the people to ensure we deliver on the objectives. It’s got to start with what are we trying to achieve and then everything else follows from there. So, it’s about structure.
What role specifically does an enterprise architect – the EA – play within that, do they bring all those elements together?
Absolutely. We have to understand company strategy, the technical components, the functional components, everything that’s required, the transformation, the people, the processes etc .. We have a lot of people in our team to support, for example, change management, data analytics. And we bring in experts as we need. But we need visibility and insight into what are we trying to achieve and therefore what can we put together to deliver that for the customer. So, we’re the ones overarching the architecture, pulling it all together.
So, you keep pojects on track. I was going to say, if you took the EA out of any IT project what’s the danger for the project?
Without an enterprise architecture, the danger of that project is absolutely 100% scope creep, no clearly defined direction, no clearly defined delivery, your dates go, your budget goes up, everybody’s running around in circles. I mean, the delivery team will absolutely 100% try their best to get the requirements, but if the customer hasn’t got a clearly defined framework or scope, the requirements can be how long is a piece of string, and then bringing that back in to deliver it in a particular timescale is a nightmare. So, you’ve got to get the scope and the strategy first.
What you end up with could be completely different from what you originally conceived because of that scope creep. In your experience as an enterprise architect, what does a good project look like? What are the best projects that you’ve seen delivered?
That’s a good question. A good project is when the customer and the partner are on the same page. And we all understand the components that are needed. The fact that the project has challenges comes down to people and resources, because not everyone can leave their day job behind, they have to juggle, and we have to respect they’ve got to juggle. So there’s a recommended approach, but you’ve got to work together. An EA phase starts by working with the customer, together in a collaborative way to aim at the same goal. So, you create the relationship. You create, I suppose you’d call it a trusted adviser, you’re in the face of the customer and everybody’s on the same page, then it works really well.
How to make your new Microsoft project a guaranteed success
In 10 minutes, this brochure shows you how to launch projects in the quickest possible time, resolve mistakes and mishaps, and keep your ongoing costs to the barest minimum.
In examples of projects working well I hear about are those where the initial buy in or the approval or the project going ahead comes from the top. Those people understand why there’s a need. They get why there’s a set process to fulfil that need. So those best projects tend to have internal senior stakeholder. Do you see the same thing?
Yep, absolutely. And that’s why we start with a strategy session. What is the objective for the project sponsor? What are we trying to achieve? Because without that, you don’t have clear direction. So, everything that happens throughout the enterprise architecture phase, and then following on into project delivery, reinforces that goal the project sponsor is trying to achieve. It allows us to challenge the project team. To challenge the customer and say, well, this isn’t in alignment with that budget principle or that project scope so tell us why it won’t work for you tell us why we need to do something about this particular workaround, or gap, or something like that. And then we work with the customer to overcome that. If we didn’t have a clearly defined scope, strategy, and direction, it just runs on forever.
I spoke with your colleague, Mike, recently, and he said that as an enterprise architect, one of the most interesting projects that he gets involved in, and some of the most successful projects he gets involved in, are those where there are lots of challenge, and there is scope to challenge the thinking. You may come up with an idea and a route forward and a framework and all the rest of it, but he says that, when you’re able, as an enterprise architect, to challenge the way it’s been set out, that’s when things work, because that’s when you kick out the problems that could appear later on. Is something you see as well?
Mike’s absolutely right. The challenge that we have is sometimes customers will come to us with a, this is what I want and therefore they’re very blinkered or have a narrowed view. When stepping back and allowing the Enterprise Architect to do the full assessment, from the technology, functional, people, process change, management, etc, we can come back and put forward an alternative view and say, well, actually, we think you’re going to get better business value if you chunk it up in this approach. Sometimes we’ve had examples where we’ve made the customer change their mind, and go, I would never have thought of doing it that way, and therefore we can explore that avenue further. In the end, the customer gets what they want. But they didn’t realise that’s what they wanted.
I get why having people who are able to challenge those things to help us shape and change and improve projects. I want to ask you something a little bit personal now. How did you get into the role you’re in now as an Enterprise Architect? Where did that come from, is it something you wanted to do when you’re at school, for example?
No, I’m actually a qualified accountant. So, I’m completely left field. I’ve done finance and systems implementations for the better part of 25 years, then as a qualified accountant, Finance Director and then at the end, I thought, you know what, I don’t want to be this. I don’t want to be in the finance circle anymore. I want to help people deliver systems in a better way so I hopped across the line as a consultant, a finance consultant, initially, and then from a finance consultant, finance, lead and Solution Architect and from my perspective, it just pulls all my experience together from the finance, project delivery, from being an end-user having a project done to you, to leading a project to make a successful implementation. To then stepping back and being privileged to be an Enterprise Architect and go to customers and help them achieve what they want.
Jaqui believes that without an enterprise architect, there’s the real danger that any technology project is at risk of scope creep, because it is operating without a clearly defined direction, or without a clearly defined delivery path. And without each, your project dates go, your budget goes up, and everybody’s running around in circles.
Part of the Enterprise Architect role is to bring project stakeholders together to help them shape the project, so it is fit for purpose. This means aligning objectives to delivery. It also means challenging the status quo because maybe, just maybe, there is a better way to deliver your project successfully. And if there is, an Enterprise Architect will find a way.
Thanks for listening, until next time, take care of yourselves.
Submit your contact details and we'll be in touch