How to Project Manage without Project Management at SKILup Days 2024

Hi everyone, and thanks for joining the session. How To Project Manage Without Project Management. I'm Jim Stevenson.

Um, I'm the founder and CEO of Blech Group. Um, a bit about me and my past. I first started writing programs back in 1980.

I am genuinely that old. Um, first went into production in the nineties, um, and that's way back in the days of Supercar, dBase and Lotus 1, 2, 3. Um, I founded Bletchley Group in 2000, inspired by the work done at Bletchley Park, um, by Alan Chewing and Tommy Flowers to create the colossus and the bomb.

Um, and I bonded on the basis that technology's cool. It's fantastic. I love technology, but it really needs to serve a purpose and without serving a purpose, it's just cool technology.

So we've formed Bletchley Group as a basis of how do you use and get value from technology, but today we're now, um, strategic advisors and consultants and we've got a much broader remit where we help companies to grow with through strategy and transformation. And that's very much what we do today on a day-to-day basis, is find the strategies and help businesses transform to leverage technology, opportunities, markets, global expansion, whatever that is. And there you can find my contact details.

If you want, reach out and say hello. Feel free to, I'd love to chat to people. So my email's there, my website's there, and my LinkedIn, which is probably the best way to connect with me.

So, again, why are you talking to or why am I talking to you guys? Here is some of the clients that I worked with before. Um, lots of clients here.

These are the big ones that hopefully you'll recognize most of the logos. There's been a ton of smaller ones that you wouldn't recognize the logos, so they don't make it onto the slide. Um, but I work with companies from a million, 2 million turnover all the way up to 70 billion.

Um, the, the size of the business isn't what gets me excited. It's the opportunity, it's the challenge that it brings and it's helping it to grow and succeed. So let's get into it then.

First of all, before we can talk about project management and how you project manage without project management, let's define what project management's all about. What's the objective of it? 'cause I think this is a key thing going forward.

Um, the first thing for me then is project management is all about, um, delivering business objectives, business outcomes, business results. And I'm sharing this letter with you purely 'cause it's my go-to for everything. Um, I love this letter.

It was written in 1997 by Jeff Bezos to all of these shareholders. And I've highlighted there the word that for me is just sums up everything. We will relentlessly focus on our customers.

Um, and that for me sums up what most businesses should be doing, but in a wider context, project management is about delivering business results. I personally think customers are a huge part of that, but it's not always. Sometimes it's business efficiency, sometimes it's working with partners.

Um, so project management delivering business results, and I'm going to emphasize business results there. Um, so if we're all about delivering business results, why is it KPMG and lots of other companies? Um, always say that 70% of OGX fail, or in this specific case, 70% of organizations will experience a project fail in the last 12 months.

Um, I don't know that that stats true KPMG obviously think it's true in their experiences, but I do know from my own experience, there's a huge amount of projects that just failed to deliver. And I want to explore that a bit further because I, again, I think this is key. There's a difference now between a project failure and a business failure.

And I think if we talk about projects, I think the vast majority of projects succeed. They deliver what they said they were gonna deliver, but the reality is they don't deliver the business outcome, the business change, the business results that were there. And I think that's a fundamental challenge within project management.

That the project itself has a set of objectives and you tick the box in those and the project successful, but the business didn't get the value from it. Um, and that I think is worth exploring further as we go through the this talk as well. So let's look at some of the new approaches of how we explore these issues and how we overcome them, which is probably the most important part here.

Traditionally, everyone's seen this and you would have project, um, uh, successful project delivery is all about compromising your scope, quality, time, and cost. Um, and pretty much the triangle says you can have one of those, but at the expense of two others. So if you wanna save money, it's gonna take you longer and you might not get all the scope that you want.

If you want the scope that you, you, you demand then gonna cost you more and probably take longer as well. And that's the traditional, um, uh, triangle. And that's all about project delivery.

And people make these compromises based on the project objectives, the project timescales. How do we tick the box in all of the project based objectives that we have so that the project is, uh, is delivered successfully. But I think that also comes with a mindset for projects.

And generally projects have a start and a finish. Um, which means you are investing in that period of time where the project starting. You're changing some systems and you're finishing.

And that very often can be driven by your finance. Um, team finance people love, um, that mindset because it gives them known quantities, it gives them a set amount of cost, a set amount of, um, a deliverable and a set amount of time. And that's always a challenge for the projects.

But finance people love the certainty of it. But it also brings with a a an issue generally. Um, when you're setting up a project, you set up a whole new team.

Every team's slightly different. You might have different skills, you might have different people, you might have a different leader. Um, you might have different whatever.

But that brings with it a team getting a learning curve. Um, it's a domain they've never worked in before. It's a group of business stakeholders.

I've never worked. So you are learning constantly as you're going. Could even be a whole set of m source code that the the team have never seen before.

Um, because of that, the cost vary. Um, the original, um, project to get your, um, business case done will have a variable cost because it's gonna be three months, it's gonna be two months, whatever that period is. And then you go into the project and, and you, you are kicking off doing development and you're scaling up the team and you've got a big, um, uh, bunch of resource in the middle to deliver.

And then as you tail off and you get into testing and, um, finalizing, um, systems changing and, and project management, um, then the, the, the shape of the the expenses varies throughout the, the project. And that can be a challenge very often as you go. Um, but the team owner, the team ownership is the deliverable.

Our objective is to deliver this project and deliver this project well on time to cost and to the agreed scope. And because of that as well, quality's a gateway. Quality's a a a ticker box.

Um, 'cause let's be honest, um, after the project's delivered, the project team will move on to other projects, other things they don't have to deal with any project quality issues that they build into the system. They're not responsible for any legacy code, any tech debt, any business issues, any compromises that the business is doing manual workarounds for or anything like that. They've delivered a project, they tick the box and they've moved on.

So projects focus on project delivery 10. They also tend to add technical complexity. Um, is very unusual that a project will actually go through the effort to reduce technical complexity.

It very seldom does it. Um, remove code, simplify code, simplify underlying systems, simplify interconnections between systems to make things better. It tends to add technical complexity 'cause it's always adding functionality that the business wants.

Taking away technical complexity is always a nice to have afterthought. And it's always the first thing that gets squeezed in a a project. And as I said, the team tends to be disbanded before the benefit.

They've all moved on. Um, and no one knows in that project team whether it delivered the results, whether the quality was okay or anything else. So that's very much, at least my experience, and I'm gonna assume the vast majority of your experiences and and projects as you work through them.

And these projects can be anything. They can be software engineering, they can be infrastructure, they can be business change, they can be business process change. They've all follow very same model and issues.

So then we got into this whole kind of agile mindset thing whereby, um, in fact, before we get there, the the, the business waterfall for traditional projects. Um, the business comes to you and tells you what they want to change. The designers change it, the engineers, um, write it, the marketing team market, NH feature updates or what, whatever that is required to deliver on that and get it out to the the industry.

But then we go into this, um, uh, agile mindset, and I'm gonna use the word agile loosely with a small E 'cause I think agile in certain circles is an overused term. People don't quite understand it. And now it's an umbrella term for a lot of things.

So I don't want to use that term overly much, but the principles of it are, are just fantastic. We go into this agile mindset whereby it became a really race, um, to move forward. And rather than actually, um, approaching, uh, development of any kind as, as a a sequence of events, agile wanted us to more approach as holistically as as rugby.

So passing the ball between people as we all run down the pitch at the same time. So what that led to us was, because agile effectively came from the startup community back in 2000, um, the business would still be waterfall. The design would still be waterfall engineering would then be agile, and then marketing of the product at the end would be waterfall.

So we got this kind of iterative approach halfway through this traditional cycle, which didn't really add an awful lot of benefit, and very often added more confusion because the engineers were going back to the designers and the business with half finished work and saying, what do you think of this? Um, so it, it took a lot of, um, it took a lot of education and a a lot of working together to make that process work. But then we got into, the designers liked the process, they wanted to iterate as well, and that was great.

But we still fundamentally, and actually we, we also got into the position whereby the business started being involved in this as well, but it was still very much a waterfall process that each part of it was iterated and that didn't really deliver the values because we weren't really in this. Everyone is in the build phase. Everyone is a measure phase.

Everyone's in the learn phase. And we were all in this scrum team running down the pitch together, passing the ball through each of these phases. Um, so ultimately for, for getting the true value of agile, you need to be in this, this mindset to make this work.

But before we get ahead of ourselves, um, what's the benefit and what's the difference then between the project mindset and this business mindset domain teams? I'm trying to avoid the use the, the use of the word agile there. You can tell.

So the business mindset, the domain teams, um, if you are running a team that is specific for a certain domain, which is a really good thing, what it means is that you invest in that domain. You're no longer tied to a 12 month finance cycle of your budget commitment. If you've got a domain of a product, um, whether it be a software product or anything else, um, you're committing to the lifetime of that product and it will change and you'll evolve.

But it's not a 12 months. And then we'll see if we've got money next month, next year. For this, you have to invest and commit to the lifetime of the product in the system, otherwise why are you building it in the first place?

But it also gives the team the benefit that once they're starting to work in this domain, whichever it is, I'm gonna use a retail example, um, once you're working in this e-commerce website, um, um, the build domain knowledge, in fact even the, the retail example is probably too broad. Um, we'll, we'll, we'll define it a bit more than that in a second so that we've got some something tangible to talk around. But the team then start to get the domain knowledge.

They know the source code, they know where the, the skeletons are in the closet. They know what the business users are needing. They know the bits that have got the tech debt.

They know what the business operates, they know how the customers are reacting because they've got domain knowledge equally because the team is fixed in this envi environment, and I'll explain this in a bit, the costs tend to become known. If you've got a domain knowledge team, an agile team, and it's eight people, it's eight people this week, next week in the following week, you know exactly what the cost is. But in this world, because of the business mindset and the domain team that you have, the team have ownership of the product and the system success.

If you build something that just doesn't meet the quality standards, you are the one that has to fix it in three months time when it all breaks. So you are built into this, the, the need for the team to have the quality within it, the business results in it, the, the outcome that the business want. Um, you are the one that, that is, has the ownership of the, the product, the system, whatever.

And you, you've got the longer term. You're not just looking at a project to change a system, you are looking at the lifetime management of the system. You're looking at the lifetime quality of the system.

And because of that, when you get into these domain names, the product, the the systems that you're looking at, you tend to focus on the business value. And that's a fundamental shift that I started off this, this talk, talking about the difference between, um, business success and systems or project success. In this, this model, the domain team, the business mindset comes to the fore because you own that success.

So essentially what that does to our traditional tri, tri, uh, triangle, sorry, or triangle, is the key elements are still the same. But when you're doing a compromise between those key elements, what you're actually doing is you're compromising for the business results that you're trying to achieve. So it may be that you do a phase one, which is cheap, it's quick and it's low in, in scope, but you've got a business result early on in the process.

And then you iterate on top of that with something that is more substantial, better quality, but it's the business outcome that you're looking for. You're no longer looking at the project success as your core metric to how you're compromising between your scope, your cost, and your time. You're looking at the business objectives that you're trying to get there.

And I, I often think that the best thing that, uh, an engineering team can actually do is to go back to the business and say, we can deliver half of what you want early, but it gets us into the marketplace. It gets us to understand what's happening and it gives you feedback on, on how this is working. And the engineering team can be suggesting that they can be leading that process to help the business through this, this understanding.

So why would we want to do this? What's the benefits of this agile business domain? Logic thinking, I really should find a term for it if I'm honest, but, um, let's keep going.

One, it gets you into the market, um, faster and you start realizing value quicker. And it may be that you're only realizing part of the value quicker rather than all of the value, but part of the value three months in rather than all of the value nine months in is still better. So speed to market, speed to understanding realize value and value in this instance could easily be customer feedback or user feedback because you are actually getting into their hands or part of the system into their hands early.

And that's hugely valuable. Alongside that, you tend to find, because you're working in a much more iterative way, um, higher satisfaction comes, customers can see that you're changing, that you're updating, that you're listening to them, that you're reacting to them and you're being quick to do things. And again, this could easily be internal customers.

I, I remember when I worked with the Guardian, um, we undertook a, a, a project, uh, uh, to do continued delivery, continuing integration con continuous delivery. Um, it took us a few months to deliver it, but fundamentally what it meant was the business stakeholders were no longer pushing us to get everything into every release because they knew that actually if their, if their function, their feature wasn't in the next release, it didn't really matter. 'cause they could do another one in three and a half minutes rather than every two weeks.

So generally these way, these ways of working increase customer satisfaction significantly. And to be honest, they have a, a impact on your culture. These ways of working make you collaborate better between the business.

Um, design, engineering, user experience, customer service, product management, marketing, they just meet you, work better together. And that's always a good thing. They tend to minimize risk because you're releasing things as you go, whether it's into a testing environment or a live environment.

You're releasing things early. So you see what happens. You see the impact and the risk of, of failure is easy to see because you can see how much time you've got, how you're burning through your cache, and you can change your scope and your time and things accordingly.

Um, and they tend to have fewer bugs. Um, and if I'm honestly don't know why, they just do. Um, I think the software tends to be better, probably because the person that creates the software isn't throwing over a wall to someone and testing to test it, who throws it over a log into someone to, to really sit into live and then through they throw over the wall into someone else to support it.

Um, if you are writing the code and you have to support the code later on, then you tend to make sure that the code's better, but fewer bugs. And lastly, like I said, if you've got a domain team that is eight people, you cost control is much easier. It's no longer what's the cost of the team.

It's how much can we get the team to do within the cost and the time that we can give them to achieve the business results. And it changes your mindset quite significantly as you go through that. So, um, new approach to project management.

If you want something you've never had, you must be willing to do something you've never done. So I'm not for one second saying that this is easy. I I I've taken dozens of companies through this process to make these changes.

Every one of them has been really happy at the end of the process. Um, but it is a challenge getting through there. Um, and if we have time, I'll take you through some of those experiences as well.

Um, it's now quite important I think to run through quickly. Um, the agile manifesto, and I kinda hate this 'cause it kind of elevates agile into a whole big different world that I don't think is particularly fair and it's almost, uh, treated as a blocker to moving forward. The reality is though, I think it's it's really important, specifically individuals and interactions over processes and tools.

Your people are your best asset. Um, trust them to do the right thing, set 'em the right objectives and let them let them get on with it. Working software over documentation, no customer has ever said that's the best system design I've ever seen.

The one software that works and they can use customer collaboration over contract negotiation sat at the same mindset. We want to be using it. We want to be, um, um, getting it in front of customers to get the feedback and the knowledge, not spending days and months negotiating over contracts or, um, paperwork.

And then once we've actually got this collaboration and working software out there, we need to be able to respond to change. So as we get told that something isn't working well, that's when we optimize and that's when we get lots of value from this. But it's not just agile.

I've, I've mentioned agile a few times. Lean is also, um, a huge part of this. And if you understand agile, you understand it, lean is a, it's either the subset or it's the superset depending on who you talk to.

But, um, the, the principle of eliminating waste, amplify learning, decide as late as possible, deliver as fast as possible, um, empower the team. That's huge. Build, integrate in and see the whole, you've gotta see the whole picture before you can actually start working on subsets of it.

Otherwise, the potential is that you'll do something that isn't quite building onto the the hole. Um, and this is a personal thing for me, and I know lots of you won't have the choice, um, to decide on this, but if you do, I don't think what I'm talking about here is prints, prints too agile or safe. I do not believe that, that those actually follow the manifesto.

No, hang on. Where is it? It's this one.

I think those are processes and tools over individuals and interactions. So I think I can see the value for them. I can see the, the benefit of them, but I think they break the manifesto.

So you need to be aware of that. My personal choice is to use less the large scale scrum. I think that's a much better, um, framework.

It works hugely better. Um, it achieves an awful lot. It keeps the team empowered.

It doesn't follow a process that that interacts and interferes with, with what you're trying to achieve. But I, I am willing to say that everything in life is a compromise. Um, less is a compromise.

Agile is a compromise. Um, prince is a compromise. Safe is a compromise.

You need to, uh, understand what is important to you and then compromise where you need to. And that's just a simple truth. I find less covers most of the things that I need and it's the least compromise.

But there's lots of ways of of, of skinning a cat as they say. Equally, I think I love this. I think this came from Gartner actually, and the pace layering method and it's understanding which parts of your system do what and why.

Um, so you've got systems of innovation whereby you should absolutely be, um, iterating, experimenting, working with your customers and moving forward. You've got systems of differentiation, which is all about what your customers are doing, how they operate and how you can be different. So your pricing model, your business model, those types of things as they're built into the system.

But you also then have your systems of record and your systems of record are essentially your base count, uh, accounting systems. You don't want those things changing every day, every week, every month. So different, different parts of your systems need different, um, attention and different ways of working.

And then the chart here shows, um, if you've got a front end, um, system of in innovation, it may very will be that you open up an API and allow customers to develop their own software on top of yours or, um, just basic social media for content development, um, agile and lean working there. And they work best in systems of innovation. We can work through the stack, um, traditional development and then waterfall.

So depending on what this chart, to be honest, it's about 20 years old now, if I'm perfectly honest. So I think most of this can now be done in Agile and lean, although this chart would indicate otherwise. So how can you implement all of these new approaches into your organization?

Get the benefit of this. Um, the first thing for me is, um, align your business and engineering teams is far too often that the business come wanting change in engineering or DevOps or IT ops, whichever you call it, are pushing back. I can make that change for you, but it'll take us six months and you we're too busy.

It'll be put into the, the, the, the calendar in a year's time. You've gotta work much closer with your business and engineering. At the end of the day, you are all paid from the same bank account.

You're all trying to achieve the same objective. So you need to be aligned in working together. And for me, part of that is setting business objectives and KPIs and the engineering team should be responsible for those business objectives and the KPIs, not just delivering the project.

And that for me is a fundamental change. The engineering, DevOps, whichever you want to call it, they have to be accountable for the business objectives along with the business team. Otherwise, we're always going to have this where this situation where the, the project can be successful, but the business objectives were never achieved.

You need to empower your teams. I happy you're a very classic agile team structure whereby the team comprises bits of everything that you would need. But what it allows the team to do is to control its own destiny.

It can decide what it wants to do within the parameters of prioritization and business need, but it decides how it does it, what it does it, how it's gonna be successful. And it's not relying on waiting three months for someone else to do something before they can move on with their work. Ideally they own a piece of the code, the piece of the system, a piece of whichever you're changing and they can deliver all of that themselves so that their success is their success.

And then finally, and monitor and reevaluate. This is actually, I'm not sure if I'm allowed to show you guys this, but this is the OAN dashboard which was created by a a, a really smart guy, um, Graham Ley at The Guardian. So it's a bespoke monitoring system for the Guardian newspaper.

And you can see there's incredibly simple but hugely, hugely, hugely, um, effective. It tells us what the traffic on the website was today. It tells us what the traffic was on yesterday and it tells us the traffic, um, last week.

And that's more than enough to tell us just at a glance that everything's normal or there's something gone wrong today. Today's traffic is significantly less than yesterday's or last weeks. Um, and it's not designed to give you the answer.

It's designed to highlight the fact that you need to go and find what the problem is and what the answer is. Um, and it is genius for that. Genuinely is genius for that.

This is several years old, probably 15 years, maybe more. So don't look at the numbers. I'm sure the guardians traffic is significantly higher today than then.

So moving forward, I hear some of you saying that won't work for us because we need legal involved, we need compliance involved and all those things. I've worked in, um, legal compliance businesses before. I've worked in insurance companies, finance, FinTech, and you're completely right, you need legal and compliance, but the way to get around that isn't to not work in this way.

It's actually, it's a, those areas into your team, as I said, your team needs to own everything to be successful. And if it can't do that because it needs a legal review, have one of the legal, um, team work within your team. It doesn't have to be full-time, um, but they can be readily available a day, a week, two days a week, a morning a week.

And that's your time for that legal person to give you all the, the, the legal advice. How should you do things? What is compliance?

How do you make it work? And to be honest, I add in there marketing as well. Because very often if you're doing something that is going to go to your customers, you want to include your marketing team early into what you're doing and how you're doing it so they can start working on how they're going to present it to the, the market, how they're going to leverage it.

Are they going to do whatever to do a pre-release or how it is. But second, these people into your team as opposed to looking at at them as third parties that you need to go to and get advice from. I hear lots of you saying that one for us, we, we have very large complex programs and we need lots of coordination and we need it all to come together.

This is where less comes in for me. And this isn't less, this is a, a model that I produced after working at The Guardian to do this 15 odd years ago. But you can easily coordinate that across your teams.

I I've done this often. Um, I remember one situation whereby the Guardian sold a, a piece of content, um, to a big mobile phone provider. Um, the Guardian had their, uh, 15 teams, 15 agile teams, scrum teams, um, and that one piece of work, um, touched 13 of them and we had to deliver all of that in, I think it was 30 days.

I think the countdown was 30 days. I had a big whiteboard with 30 on and counted it down. And we achieved that using this, this model here to coordinate across them.

And it worked very easily, very well. Um, although 30 days to deliver something so complex was a bit of a, a stress and then it won't for us. Um, we have large complex programs you can, and again, this is an example of, um, the, the, the way that we worked at The Guardian with 13 outta the 15 teams all working in this one program.

Um, you have one team that's taking the majority of the work. You have another team that's got a lot of work. You have a third team that's got some work.

You've got a fourth team that is, wants to finish off what it's doing, but it's not gonna need all of the time. So it can, it can wait a couple of scrums, a couple of, um, sprints and then it can start and it'll still be finished early 'cause it, it's got it coordinated and planned. You've got a couple of teams that can do some work at the base, the start and then just wait and then just before they go live, I can tweak the last thing and then we can go live.

And the green arrows there, the, this, the, the sprint where we go live. But the real beauty of all of this is if you use feature switching, um, and this is a term probably 15 years ago, I'm pretty sure there's a, a more modern term here. Um, what you can actually do is you can have some teams working on your, your code and releasing it early into a live or a, a staging environment while they then move on to other things.

And that would allow, in this case, team C could release into a staging environment that the work that team B need to be working on so that they can move on with their things. Team E would be finishing and and scrum three to allow team B to keep going with their stuff. And then all behind this feature switch, sorry, behind this feature switch, they're then releasing one goal on the release date knowing that all of their work has been done.

Some of it has been in the live environment for 2, 3, 4 or five weeks. Um, and you're very, very conflict. So there are ways to coordinate this.

Um, for large organizations, large complex programs, it's very doable. And that is not a reason not to go ahead with this, this way of working culture drives great results. Jack Wel said it should resonate across everything you do when building or rebuilding culture.

Create one with customer focus, open communications, permission, empowerment, humility, innovation, change and fun are celebrated. And that is just so, so, so relevant. I've done lots of these transformation programs for lots of clients and I will guarantee you that every time one of the biggest factors to success is the culture is getting people's mindset to change, is getting the culture to work for them.

So what is a good culture? Um, I think this is actually one that we created the Guardian to be honest, but it's, it's reasonably good as a starting point. You it needs to be commercial, which is strange in a, an engineering team.

To think that you need to be thinking about the commercial reality of where you are. Customer-centric, transparent, collaborative, you need this growth hacker mindset whereby you're trying to do as little as possible to have as big an impact as possible. Um, empowered data-driven, passionate, innovation and agile so that your con agile probably should have a small area.

So it's more the mindset of agility rather than the process itself. Um, and again, culture, a great working environment. This is again, a photo that's probably 15 years old, but I'm pretty sure this is the SAP Hanna office in Silicon Valley.

And you can see they don't have walls instead of walls. What they have is sliding whiteboards, all the tables and all the chairs and all the, the, the units and things all have wheels on so that any given day you can fundamentally reconfigure the office to work with the people that you need to work with, collaborate on a very specific project, move to to do something, work within projects of, uh, of large teams. But it creates that environment whereby you're encouraging collaboration, you're encouraging working together, you're encouraging, um, innovation.

Um, and then lastly, I think this is probably the last slide. Um, we can't solve the problems by kinda thinking we use when we created them. A lot of this is changing your mindset, how you work, finding the solutions.

And I find that a lot of that comes down to, um, changing your perspective on what you're trying to achieve. Project success is no longer what you're trying to achieve, it's business results that you're trying to achieve. And if you keep that in mind while you're delivering a traditional project that you're 50% there, you're trying to achieve the business results, not the project success.

Um, that is kind of what I had for you today. Um, so just to answer the question, how do you project manage without project management? The real answer to that is you create teams, you create environments, you create structures, and you create a culture where the team project manage themselves.

It makes your job as a project manager fundamentally easier, less stressful. And to be honest, it makes you way, way, way more successful. So that's it for today.

I hope you found that useful. I hope I didn't go too quick, but there was a lot in there. I think this is normally a four hour workshop that I give compressed into 30 minutes.

Um, if there is something I can help you with, please feel free to reach out. As I say, I've done this for lots of organizations, I've got lots of war wounds and scars and I'm happy to help you avoid those war wounds and scars. Um, reach out, chat.

I'll happily help if I can. Thanks for coming.