EP84 The hidden risks of documentation in Project Management!

Dante Healy [00:00:00]:

Hello everyone, welcome to Business Break, your project management edge. I'm Dante Healey, and together with John Byrne, we're peeling back the skin on the dirty word of project management, and that is documentation. So we've seen it all. The project team hits the go-live, pops the champagne, and hands over a 200-page PDF that nobody will ever read. And 6 months later the system is still a black box and the original project team is getting frantic Slack messages at 3 AM asking how do you do this, that, or the other. So the question I'm going to pose to you, John, to start off this discussion is if your project team disappeared tomorrow, would your business actually know how to run the system they just built, or would the wheels fall off inside a week?

John Byrne [00:00:53]:

I suppose it depends on the project. You tend to make more bespoke, do more bespoke projects. So I'd imagine the wheels fall off if your team disappear, whereas I tend to do system implementations of existing systems.

Dante Healy [00:01:05]:

So you hope that the, um, the platform has generic, like, user manuals already pre-produced. Yeah, because I deal with custom microservice deployments. Which are basically specific pre-built apps that are stood up inside of a few months. They're relatively small, but then they end up getting built upon, which becomes like almost a system in and of itself. But yeah, I guess that's, that's one nuance that we have to, have to pull out really.

John Byrne [00:01:41]:

Yeah. Yeah. For, for me, the documentation piece is more during the project, you know, the, the project documentation. You know, where are we to get the, you know, project information, initiation documents all sorted, getting all that type of thing. That's for my projects, the ones I usually work on, that's where I kind of come from. At the end, we just hand over and it's a system that's complete and integrated and it wouldn't be too much configuration or for my project. So I think you're probably the more involved with bespoke projects where there is no pre-existing documentation that exists. So you have to create that as part of your project.

Dante Healy [00:02:23]:

Yeah, exactly. It rolls from the business requirements document to the technical specification, which usually involves architectural design decisions, relative trade-offs, and things like that. And then at the end, you you focus the documentation towards more ongoing support, maintenance, and even training for the users. And that all happens based on turning a vision into something more specific that can guide people on how to use the new systems. But yeah, the, the challenge I find is that documentation tends to take second place to actually building the tools. Therefore, what happens is the developers and even the business users tend to leave the documentation, the heavy lifting part of that, until the end. The irony is usually human nature is that they hate writing documents, but they love finding an area where they can just reference something like a how-to when they need to understand what's going on inside the ecosystem. So that's the challenge we face as project managers, is getting people to do documentation, because it's not just bureaucracy.

Dante Healy [00:03:51]:

It's something that's actually very important if you're building something that's considered going to be a long-term or even a medium It's a short-term solution, but someone needs to have to manage it. And there has to be a handover and an exchange.

John Byrne [00:04:07]:

I imagine though, you know, that kind of documentation, I mean, you know, you're the one doing it, but I'd almost consider that, like, that needs to be part of, built into the project, that not just left up to, I mean, when you look at documentation for being able to follow it, be able to do it. That's a completely different skill set to creating a piece of software and doing it. I mean, that's, you're going out, you're getting somebody who has design principles here for creating great documents and breaking down and that. So should you be building that into, as a separate project team who have to put together and publish a document? Or are you just completely relying on the developers? Makes sense.

Dante Healy [00:04:59]:

I guess it depends how it's funded and to what extent it's funded, because we have contracts with vendors who are building this stuff. And then as part of that specification, work documentation is always there, but sometimes it's treated as, shall we say, a secondary thing that eventually gets rushed. At the end, and then you find that people skip fundamentals. For example, you know, documentation should be more like a search engine rather than a library book. If the sections aren't searchable and easily traceable where you need to refer, not the whole document, but just one specific piece of it, then you need to be able to just target that bit you need at a point in time, rather than have to scan through pages of pages of verbiage.

John Byrne [00:05:57]:

But even, even with that, I mean, if you're relying on developers to write it, it's not going to be readable to somebody who's actually using the end system. They're not developers. So how, how do you make sure that what's been written down is actually understandable by the end user?

Dante Healy [00:06:15]:

Because the end user, what you have is a functional lead as well as a technical lead, ideally. So you have that symmetry where someone understands the business context and enough of the technical mechanics to actually know where to look inside the— whether it's a front-end UI issue or a back-end data issue, for example. But, and to be honest, what you end up with is a product. And the piece that the user's interested in is, for example, how do I get this information out? Or how do I enter this information in a lot of the time? Or how do I put— yeah, I mean, that's it, isn't it really? Information in, it gets processed and it comes out in either queries or reports. At least in the projects I work in, which are mostly finance related.

John Byrne [00:07:10]:

So the key thing there then is, so I'm, I'm, so I'm basically being inquisitive here because I don't do your type of project. So, and so I'm actually asking these questions because I don't know the answers.

Dante Healy [00:07:22]:

Oh, okay.

John Byrne [00:07:22]:

You know, if you, so like you mentioned there, you have the developer, but then you, the development leads and then you have the functional leads. I mean, ultimately the idea would be that your project team is actually disappearing, so you won't have the developer lead anymore. So there'll be nobody there to answer. So how, how, that's the bit that I kind of would be worried about most if I was actually having to create the documentation for a brand.

Dante Healy [00:07:49]:

When your technical leads are rolling off and you're, you're running out of runway for them because they're still, for example, they're still fixing bugs. When they should be switching towards handover.

John Byrne [00:08:01]:

Yeah, and how exactly? So there's kind of almost like two different types of documents then that you need. You need technical people to write technical documents so that if anything needed to be adjusted in the future, a new team could come on, look at these technical documents and know exactly where everything is and how to adjust it. But then you also now need to create the documents for the functional users who have probably no technical ability whatsoever, so that they can use the system that you've just created. And they can use the system in the future, like it's not part of a handover because there'll be new people coming on and information might get lost, knowledge might get lost, I should say, in a handover situation. So you, how do you make sure of that? I mean, I would, the time to do both, do you try to create one document that covers both or do you create two different sets of documents or? What way do you tend to work out?

Dante Healy [00:08:55]:

I've seen the extremes on both sides. You know, my ideal scenario would probably be start with the functional lead to get the business context and that level of abstraction on why the system exists and how it's meant to work. And then beneath it, you, you provide enough of the technical architecture. I mean, these days with document sharing, it should be possible. Then there's also different documentation tools, multimodal ways of recording information. Even when you are doing knowledge transfers, you have the project team handing over to a production support team. They will have a few more, well, maybe my experience, more than a few sessions where they share what's happening. How the system was built, what is in the, was in the source code and how it's configured.

Dante Healy [00:09:50]:

And then usually the support team should be staffed with people who are technical enough to understand the basic technologies being used, or at least question how it, if it's not something they're familiar with, how is it used a certain way and how do you keep up to date with it and what checks do you need? Does that make sense? So I think it's a combination of ideally you'd want something that is a combined functional and technical document that has enough information for a support team as well as business users, but supplemented with more specific how-tos. So for example, if it's about using the system, that's less— that should be less technically competent. Complicated, and that could be supported by a couple of online videos that show, say for example, rather than writing 10 pages of words and screenshots, you have a video that just guides a user on how to enter this information in this field, click this button, and then once you see the output, click another button to, to adjust it or, or export the information that you get. As an example. So documentation isn't just what's written on a page. It can be multimodal, can be a combination of video demonstrations, how-to guides, even cheat sheets. Does that make sense?

John Byrne [00:11:21]:

It makes sense. I'm just wondering how, you know, again, I'd be fearful that technical people are the wrong people to be writing the documents.

Dante Healy [00:11:33]:

Well, they, they should be writing the technical documents, like for example, the architecture, which if they use integrations, how are they, how do they work? How have they been configured? How are they set up? For example, if they have code bases, then they should at least be able to explain what the notebooks they've set up do. If they're using databases, they give references to the databases, talk about password control, authentication, service principal keys, security protocols, what, what tech stack have they used to build the tools. And then beyond that, it's really around linking each technical component to a functional requirement, whether it's just called out or cross-referenced to a separate functional doc or within the combined— the functional sections of a combined document. Does that make sense? They're not meant to know the business logic because they shouldn't be, but they should know enough about the context of their code to understand how it meets a business need that they've been communicated about. Does that make sense? I think it's like you will not get a successful project if you have just developers just coding blindly.

John Byrne [00:13:02]:

No. But yeah, I—

Dante Healy [00:13:05]:

And at the same time, you wouldn't expect them to write functional documents. That just doesn't make sense. It's like asking a functional person to write, to decipher the code. Now, maybe they could these days with AI, but even then it would just be a guess. Right? Because they wouldn't know if the AI was hallucinating the translation.

John Byrne [00:13:24]:

That's, and that's where I'd kind of, that's where I'd be nervous about doing your types of projects. I'd be, how do you, how do you document for the functional people to be able to think? Because they're not part of the project, they're the functional people, they're waiting for you to deliver the project so they can do their job. Your technical people aren't the right people for writing that type of document. Everything up. But by the sounds of it, you don't necessarily have as part of your project a documentation team, somebody who is— that's part of their job is—

Dante Healy [00:13:55]:

If you have a well-resourced program, you'll have change control people, but that's a project work stream in and of itself, and that's very expensive as well. It just depends how you're funded and how much resource you can throw at documentation. But I'm working on the assumption that this is something that most project managers face, that they haven't factored it into their plans or their funding, and that it becomes something that at the end is rushed.

John Byrne [00:14:29]:

I'm glad I use Build System. That comes with the software.

Dante Healy [00:14:34]:

Well, the functional and technical piece is built up over different discussions. And usually there's a project lead who is the overall lead, maybe a product owner who actually understands enough of the business to actually understand how the tool is meant to work, what problems are you solving, and hopefully it's not— a lot of the time it's a lot of replacement of existing tools, whether it's an Excel spreadsheet, a Power BI report that's manual data feeds and you want to automate the data flows into the tool or something else. Does that make sense? Yeah.

John Byrne [00:15:19]:

Well, I suppose when you're doing those types of things and you're automating stuff, you don't necessarily have to worry as much about functional documentation because they won't be involved. It's automated.

Dante Healy [00:15:28]:

Yeah. Yeah.

John Byrne [00:15:29]:

So yeah. When people say documentation to me for, projects, I kind of be thinking prints too. I'm thinking documentation of the actual project itself.

Dante Healy [00:15:39]:

You mean building the artifacts?

John Byrne [00:15:41]:

Yeah.

Dante Healy [00:15:42]:

And then it failed or we went in this direction, but why? Oh, here's the scope change document. Here's how it was discussed. What were the pros? What were the cons? Here's the meeting where we brought it to the board and here's the board's approval with any caveats to that approval.

John Byrne [00:16:00]:

Exactly, exactly that, that, that those types of documents, that, that's what pops into my head immediately whenever anybody says documentation.

Dante Healy [00:16:07]:

Project documentation. No. Yeah. Yeah. And this is more delivery documentation, like the tool that the project has created as the key deliverable, but then you, you build a tool, but you forget to, you forget to provision for the instruction manual.

John Byrne [00:16:26]:

I suppose though, what my excuse for that then is, as I said, I tend to do system implementations rather than create tools. The tool is all—

Dante Healy [00:16:35]:

Implementing an existing tool. And if you do your job well, you know, it's just, you go to, you point the user to the website and say, this is how exactly it works because we stuck to that, that best practice and we fitted, refitted your organization to the system rather than the other way around and creating bespoke pieces that fit the tool to the organization.

John Byrne [00:17:01]:

Well, that's the ideal, you know, when you do things like that. And then I suppose that removes an awful lot of the documentation. Occasionally we might have to do a, you know, a little bit of a, there's a certain way of doing things that is what gives the business its competitive advantage or it's just something that's very, you know, unique to that business, that's a legal requirement or something like that. So then you have no choice but to make the software fit that thing. But again, that's kind of a configuration almost. And that is very limited documentation needed there because you've changed the system to match the functional need, which means you don't actually need to explain to the functional people how to do it. You've They've told you how to do it and you've made it.

Dante Healy [00:17:45]:

Yeah, you're taking orders. They probably already have the, the, the purpose in extreme painful detail in their head. But again, that's the other thing is you want that formalized somewhere, why it's happened, because it's good if the person who knows the process never leaves the organization and ideally never leaves their position, but when they move on, they need to hand over their knowledge to the person filling their old position.

John Byrne [00:18:18]:

I get to be quite lazy in things like that, in that when the functional people are doing that, I get to tell the functional people, you need to create a standard operating procedure document.

Dante Healy [00:18:30]:

Yeah, yeah, yeah.

John Byrne [00:18:30]:

So everybody knows. And have you got them already so that you can give them to us and we'll make sure we configure the system to match?

Dante Healy [00:18:38]:

That's true. Yeah, because I mean, you've got the executive vision in a project and that translates into business process maps when you have a business analyst trying to understand the current state and map out the future state. And then each of those points on the business process map usually translate to a handful of SOPs, as you mentioned. And then beneath that is a specific how-to document that says, for example, if you encounter a difference, this is where you would look to identify the difference and resolve it.

John Byrne [00:19:19]:

And we tend to do that, you know, because of the difference in projects that we have. And when we're doing a system implementation, we tend to do that. So those are written ultimately by the functional users.

Dante Healy [00:19:31]:

Yeah.

John Byrne [00:19:31]:

But we'll sit them down and we'll, we look, you know, sometimes they have them already and we're just going to tweak them to, you know, a few changes that we've done. But, um, yeah, I suppose technically they would be part of, um, the, you know, I have had to do that.

Dante Healy [00:19:48]:

I've had to like take screenshots and say, yeah, you know, do arrows and stuff and shapes saying One click here, enter your data here, click here, enter more data.

John Byrne [00:20:03]:

Yeah.

Dante Healy [00:20:04]:

Filter here, and then click export.

John Byrne [00:20:07]:

Exactly. Exactly. And that, yeah, I have had to do that for a few things. Luckily though, as I said, I don't have to go into the same amount of detail as you'd probably have to because 90% of it is already documented. I might be just There might be something that we've done a little bit, yeah, tweaking, we've tweaked something so the standard documentation doesn't work, or we've put in a very specific piece of, so like previously we put in the RFX module of SAP, and that was for IFRS 16 purposes, which isn't really what it's designed for, but it was, you know, it was how they decided to do it, so they tweaked it. So that's what, that was when I ended up having to take screenshots to show people, you enter here, you put it there, because like SAP has got documentation for AFX, but it's a huge, you know, it's War and Peace level if you print it off of thickness, and we were using it for one really simple thing, so there was no point, it was just easier to, look, here's the screenshots, just do that. You're not actually using the software to do everything it's capable of doing, you're using it to do one very specific task. So here's, here's how to do it for that task.

John Byrne [00:21:18]:

That was how we got to do it, but that's probably about the— and updating SOPs as well. I've worked with them, but the leads on them tend to be the functional people, and I'm just kind of telling them how it works now with the new system.

Dante Healy [00:21:33]:

And I guess it makes the whole technical architecture or technical documentation so much easier because you've, you've launched a system that has already got a fixed design, as it were. And all you're doing in theory is loading the necessary modules, inserting your own master data and functional data and configuring it so that really all you should worry about are failures and which metadata code log you need to refer to to diagnose if a failure event was to happen.

John Byrne [00:22:14]:

Yeah, and even that's, you know, very— we have very little technical documentation to have to do in implementing an existing system. You know, the system has got its technical documentation, so we don't have to— we don't really have to worry about that too much on my types of projects. I'm trying to think now off the top of my head. You know, we've had to put a little bit of code in to change something, then we obviously documented what that code was, where it was. But, um, you know yourself with these systems, there are only certain places you can put that code in to do it. So you just go and look. That's it. And then you're doing standard things like just updating, um, the, you know, the systems network diagrams, things like that, things.

John Byrne [00:23:00]:

And that's it. So I'm kind of luckier in that regard. Hence, when you're talking, I'm kind of trying to figure it out from the functional point of view because that's the only documentation I'd ever have to do. That, that's not pure project documentation. That's a handover documentation. I would try to think now, have I ever had to create technical documentation? I don't think so.

Dante Healy [00:23:20]:

Have you ever had to write anything pretty extensive where you literally refer to notebook pipelines, API calls, authentication protocols?

John Byrne [00:23:33]:

I'm trying to think now with the Probably not because we tend to follow what we're told. So like for API protocols and stuff like that, the IT section will tell us these are what you're using. So we're just telling them, right, we've used an API to connect this system to that system. And that's basically it. The protocol piece is all IT. We've just used what they told us to use.

Dante Healy [00:23:55]:

But even in the document, do you embed the email where they say this is what you use and why? No, no, because, well, like we'd normally, or would you assume that the IT team would have that recorded because it's, they have their own, should we say, their own corporate architecture patterns? Is that how it works?

John Byrne [00:24:17]:

Well, to be honest, how it's worked with us up to now. So again, it'd be the business case would have all that. And so for example, you know, parts of the, when we're making the business case for it, we have to go and we have to check with all these other stakeholders. IT are one of them. And where IT come along and say is, yeah, you know, this is what, these are protocols, the security protocols, the connection protocols, APIs, whatever you want to call it. You have to, whatever system you decide to put in has to satisfy these. And they'll document that out for us there. And we just stick that in as an appendix or whatever to the business case.

John Byrne [00:24:51]:

So that's the original documentation. So again, that kind of fits in where it's part of my project management documentation, you know, the business case, the project initiation documents, the whole type of thing. And that's it. So that's where all that stuff is. And then that's all, well, that's what's left. So we've kind of gathered that as part of our requirements, but we then don't, we don't, we document it as part of our requirements, but then we don't have to go and re-document it as a handover because, well, who are we handing it over to? Well, the only people we could hand that over to was IT. And sure, it's their protocol. They've told us what it is.

John Byrne [00:25:29]:

So they're not going to like us handing it back to them and saying, this is what we've done, because they'll say, well, where are we supposed to put this? We have our— this is what we give you. So you— did you adhere to that? Yes, you did. Okay, well, then we don't need you to come back to us and double up our things. So, so, whereas you're probably—

Dante Healy [00:25:47]:

I am IT.

John Byrne [00:25:48]:

Yeah, that's the thing. I think that's where we're— so we're coming out of from So when you say documentation, and I think that's something as well that people need to be aware of, what do you mean when you say documentation? Because one, when you say documentation, you're talking about what?

Dante Healy [00:26:03]:

I'm talking about everything, like literally the functional side and the technical side. So you've got business and you've got IT and both requirements, both sets of requirements need to be adhered to. You have the business people relying on the systems, and they're focused on really the business operating using the technology and ensuring that the lights are still on. And you have IT people who are making sure that the platforms are doing what they're meant to be doing, that the system is stable, that they're monitoring the logs to ensure that if things go wrong, that they are able to quickly diagnose the problem area. And resolve it with minimal downtime.

John Byrne [00:26:49]:

Whereas when I'm talking about documents, I'm talking about project management documents. The technical stuff will be just part of the requirements caught in there. And then at the very end, we might do something like the, you know, screenshots, just to walk people through. And where that will actually probably be built off as well as a large chunk of it is the user acceptance testing documents. You know, because with user acceptance tests, you actually are giving people the steps to follow. And then so you just take that and you stick that into an operating manual and there you go. Hand them over. Well, I wouldn't have to put as much, you know, I wouldn't have to put as much, um, talk into the handover documents because most of my documents are project management.

John Byrne [00:27:36]:

I'm not handing them over to anybody, filing them. And lessons learned is probably about the only thing that gets handed over.

Dante Healy [00:27:43]:

And I guess to that point, when you mentioned user acceptance, test implementation, and the test steps, they are often the functional piece, right? The end user is saying, well, I need it to do this. Need to make sure the system can do this. And then it's a whole, as you say, a comprehensive list step. There's usually framed around this is how I do my job. Day? How, what results do I get with the new? And also, heaven forbid, but if your project is audited, you need to be able to provide the evidence that there was good governance and that the system, if you are working on finance systems, you need to make sure the regular, they, they meet regulatory compliance requirements as well. Coming back to your point about legal. Yeah.

John Byrne [00:28:33]:

So that's, so that's That's what I think of when anybody says doc, when anybody mentions documentation to me, that's basically what I'm thinking of. I'm thinking of the project documentation for governance, for proving that, you know, everything worked, that we got sign-off, all that type of stuff. Handing over to the end users, we'll, you know, we'll help them prepare some, update their standard operating procedure documents. We'll also like, you know, we'd help them maybe update their policy documents as well. If, you know, perhaps there's more controls or something can be done differently with the new system that they wanted to do but couldn't do it with the old system. So their policies on the old system can be updated to do something else on the new. We'll help them with that. But ultimately, that documentation is their responsibility and we help them where it— and there's no real technical because technical documents were given to us by technical people.

John Byrne [00:29:30]:

So we didn't have to create them. Because they're not our technical specifications. They are IT's, you know, so they gave to us, we don't give them to them. So, you know, that's just gathered in the initiation document folder to, you know, these are the requirements we were given. So, and here's the proof, you know, later on, you'll have your user accept that here's the proof that we adhere to them.

Dante Healy [00:29:54]:

And I guess, you know, when we talk about IT, there's different IT departments, there's sub-IT within IT. So there's a lot of complexity in the organization. You have one team that are focused on specific platforms, another team focused on security, another team focused on integration, which I guess is a subset of security as well. And they overlap, right? But I guess in terms of, and you mentioned project documentation versus system documentation and business process documentation. But ultimately, all documentation forms performs a certain function, you know, and there's utility to it, whether it's about training and onboarding or about, say, an operational runbook that gives you the daily, weekly, period-end processes. You've also got troubleshooting and recovery. And then the other piece is if, for example, after you've implemented, it's been working for a year or two, and then suddenly a new system technology project is created, and you need to— it impacts your system. And so you need to be able to do an impact.

Dante Healy [00:31:08]:

What does it mean to your system if there's integrations involved or new types of data passing through or extra volume, for example? And you realize, well, actually, we're running on a, I don't know, 256 cluster, and now we need to double the capacity size in order to handle the additional volume without breaking the system. You know, so there's things like that.

John Byrne [00:31:36]:

Actually, I don't have to worry about them because my project would have finished a year earlier. So I'm—

Dante Healy [00:31:41]:

You're well gone. You're, you're, you've moved on. Yeah. Yeah.

John Byrne [00:31:45]:

But, and also most of the systems nowadays when you're implementing them, they're nearly all SaaS system.

Dante Healy [00:31:51]:

Well, they can scale up, but you have to pay for it, right?

John Byrne [00:31:54]:

Yeah, but that's it. There's not a project there. It's just the business case.

Dante Healy [00:31:59]:

Yeah, yeah, yeah, yeah. The project is you talk to a purchasing and say, I need to double my budget for this.

John Byrne [00:32:04]:

Exactly. Yeah. And that's something functional, the functional people have to worry about. It's not something a project manager has to worry about.

Dante Healy [00:32:12]:

Yeah, yeah. If you get double the transactions, you need to fund double the cost, or if the purchasing team are doing their job right, 50% uplift. Not that that happens these days with SaaS tools, especially when they're competing with AI. Costs seem to double anyway without doing anything different. The other thing I was thinking about, which probably is less relevant because it's all about the type of project, but do you remember the Agile Manifesto? And that lovely phrase, we value working software over comprehensive documentation in the Agile values. And I know we've discussed this previously, but did you have a view on whether comprehensive documentation means no documentation these days? Have you seen any changes in the Agile community? I mean, I've heard that now they're pivoting away from that no documentation to say, What is, what is essential documentation, but not bureaucratic bloat?

John Byrne [00:33:19]:

Yeah, I thankfully avoid Agile as much as possible. Actually, I don't, I don't avoid it as much as possible. I just, implementation projects aren't Agile. You know, we're not creating software. We are implementing existing.

Dante Healy [00:33:32]:

It's very deterministic anyway. You're not building something brand new. And to be honest, how many software projects are now mostly AI hallucinations? Sorry, I'm being facetious, but as you say, there's a, there's a building blocks, isn't there, on how to implement ERPs?

John Byrne [00:33:52]:

Yeah, I mean, they're nearly always going to be implementing an ERP or an EPM or something like that. CRM always going to be a waterfall project. You can break it down and, and, you know, deliver module by module rather than going one big bang. Everything if you can. But that's still waterfall. It's just miniature waterfalls. And like I said, I think I said it before, at the end of my projects, I do like to have a little agile phase where you're just tweaking and doing these people who have, they give you all their requirements at the beginning, but they can't imagine what it's going to be like when they get it. And when they get it, then they start realizing, oh, this works this way.

John Byrne [00:34:35]:

Okay. You know, we could have just done that, so I like to add on a little bit of agile at the end.

Dante Healy [00:34:41]:

And by agile, you don't mean Scrum from the start development, you mean more of a Kanban delivery system where you manage the workflow of the enhancements and they release as and when they're ready to go.

John Byrne [00:34:54]:

Yeah, and it's just a very, you know, it's, you've got your more than a minimum viable product, you've got your system in place, but there are some improvements that can be made. So you just do a to-do list though, you know, your backlog, whatever you want to call it.

Dante Healy [00:35:10]:

Yeah, I prefer to call it a to-do list because that's what it is.

John Byrne [00:35:14]:

And then just walk through it, you know, in a few, do a few sprints. So kind of, I suppose, a little bit like Scrum. Do a few sprints, maybe you've got 6 weeks, you can do 3 2-week sprints each. Walk through as much of them as you can in that 4 sprints, then reassess. Have new things come up, you know, have people realized new things to be added on? Are the priorities going to switch around a bit in the to-do list? Then do the second one and then do the third one. And then after that, it's just handover to the BAU and any more improvements will have to be done as part of the BAU. But just to give them that little bit, I like to do it. But there's not a huge amount of documentation in that part, I admit, because you're just tweaking things.

John Byrne [00:35:52]:

You're not creating that new.

Dante Healy [00:35:53]:

It's very small changes, I imagine. Yeah. And what would be your documentation would be your acceptance criteria or definition of done, depending on what phrase you're using, plus the evidence that you've met the acceptance criteria.

John Byrne [00:36:08]:

Yeah. Because in reality, at that stage, we're making little changes to configuration. We're not actually— we're not writing code. We are just changing—

Dante Healy [00:36:19]:

tweaking things.

John Byrne [00:36:20]:

Yeah. Yeah. And that you're not actually— because, you know, that's one thing with— another reason why we don't have to worry too much about doing that type of documentation that you have to worry about. When you put in an S, especially when they're SaaS, there are still a few that you can get that are on-prem, but nowadays, if you, like Oracle, I don't think you can get on-prem anymore, not as a new customer. If you've moved over to Oracle now, you have to take their Fusion Cloud. Same with SAP. I mean, SAP's gone for S/4HANA. I don't think they do.

John Byrne [00:36:50]:

Their existing customers who are already on on-prem, they can support them, but I'm not sure if you can actually as a new customer going by anymore, that everything seems to be moving to the cloud. And well, one of the handy things about that is, well, not one of the handy things, but one of the—

Dante Healy [00:37:07]:

you're locked in.

John Byrne [00:37:09]:

Well, you've always been locked in really, because even when you're on-prem, that's a huge project to move off it, which is why they still have to support people who already are on-prem. They can't just say no move. But it does mean though that you really don't want to be The SaaS products, one of the, one of the benefits of them, which is also a problem, is that you're always going to be on the latest version, that when an update happens, you'll get that update.

Dante Healy [00:37:34]:

But the downside of that is, if you make any major changes with software, you deviate too far from their core operating model, you're, you're going to be more exposed to change.

John Byrne [00:37:47]:

Yeah, it's going to break every time they update. And so you're going to almost have a permanent project team, which is a, you know, a paradox. The whole point of a project is that it's temporary, that it has an end date.

Dante Healy [00:37:59]:

So project team will be business as usual because change will be business as usual.

John Byrne [00:38:04]:

Yeah, every time. I mean, some systems update every 6 months, some update every 3 months. And if you put in a whole load of new code to make that system do something specific for you, that new code will have to be checked and tested and possibly updated every time there's an update. So you tend not to, you know, you'll tend to configuration. Yes, you'll configure the system, but you will not write new code to make the system do it. And that, I suppose, is where, where I don't have the experience that you would have, because I know you kind of, certainly the project you're on now is a big one, but it's on-prem mostly, which means you can write an awful lot of code for it because it's not going to be updated unless you specifically update it.

Dante Healy [00:38:45]:

It won't be rolled out in 6 months' time or 3 months' time by Yeah, well, it's mostly cloud-based microservices, so the platform is SaaS, but the, but the applications themselves are custom. None of it's on-prem, to be fair, right?

John Byrne [00:39:03]:

Nothing.

Dante Healy [00:39:04]:

So, and I don't know, to be honest, I don't touch most of the— there are some on-prem SaaS, SaaS platforms which are integrated through a piece of, a giant piece of expensive SAP middleware called Central Finance. Basically has this middle layer replication technology, which translates all of the local ERP settings into a harmonized data set. Then, and then we build our finance analytics tools on top of that.

John Byrne [00:39:39]:

But yeah, I mean, that's I think that explains then to everybody listening exactly why that type of, why when documentation is mentioned, you think of what you were mentioning as documentation, because given what your projects are like, and I know that type of documentation doesn't even occur to me given what my projects tend to be like.

Dante Healy [00:40:00]:

The level of understanding needed is a lot deeper, and that's why sometimes I can tie myself in knots trying to explain something. If I'm not careful, I can be too into the detail. And if you're trying to explain it to an executive who wants everything summarized in 3 sentences, their eyes will glaze over when you're trying to build a context around the problem.

John Byrne [00:40:22]:

That's it. So I don't have that, thankfully, because I even, even when it's an on-prem, it's still an ERP. Usually it's the ERP when it's on-prem. And to be brutally honest with you, I'm trying to think now, when was the last time It's probably been nearly 10 years since I implemented on-prem. The closest I've had to do to implementing an on-prem recently is just the integration piece. That was a, it was an EPM piece of software that we were putting in, but that was a SaaS piece of software, but the ERP was on-prem. So we just had to integrate with it on-prem. And that was it.

John Byrne [00:40:58]:

So yeah, and even the project now that I'm on, it's pure SaaS. In the cloud, software as a service, public cloud. Really, really, really, really handy, actually, I want to say, compared to, you know, the old days when, or people, I know you're in the cloud, but it's still, it's not a fixed piece of software. It's constantly, you're having to develop new software.

Dante Healy [00:41:21]:

Yeah. But it's, it's all on one platform where you know where to look if you want to understand what's going on. And it's literally the abstraction layer is pretty, pretty straightforward once you get the hang of it. I mean, you go into a data lake, you can see the section where the apps are built, you can see the section where they've set up the databases, you can follow how the system flows through the data orchestration tools and even drill down into where the code base sits. So yeah, as a project manager with some technical knowledge, actually quite easy to trace through if you have the time, if you need to. But ultimately, I think that's why you have documentation, so you don't have to do that, because that's kind of going above and beyond oftentimes. And if the project manager has to look into it, you've failed.

John Byrne [00:42:16]:

Well, that's it. And then you do have to, as you said, like at the beginning, that the point is not— it's fine when you're here. Well, it's a project. Project is supposed to be temporary. You are supposed to move on and finish it. And when you move on and finish it, if whoever takes over the technical day-to-day running of it probably doesn't have time to go in and look through all them things, they need the documentation to see it. They're all right, right? This, this is, this has gone wrong. This is the area where we need to go in and look.

John Byrne [00:42:48]:

And perhaps we fix it. Perhaps we set up a new project, but we might not get that. Access to the same project manager, so we need documentation.

Dante Healy [00:42:56]:

Oh, exactly. If you got a temporary project manager for a permanent role and you haven't resolved that, that could be a bigger risk than having the documentation missing.

John Byrne [00:43:09]:

That's it. But even, I mean, even if you're, you know, a lot of places do have permanent project managers, but they're permanent in the place, but you're moved on to another project. You haven't got time to go back to some other project that you did a year ago. To try and figure out, well, yeah, when I was doing it, I knew where everything was, but it's a year since I've done it.

Dante Healy [00:43:27]:

You can be sure that that permanent project manager is getting pinged maybe once every 2 to 3 months on some random thing that they worked on a few years back, and they just happen to have the knowledge because no one else has it.

John Byrne [00:43:43]:

But again, though, if the documentation was there, you wouldn't have to worry about it. So if that's happening to you, Dante, then it's your own fault for not getting the proper documentation and handing it over.

Dante Healy [00:43:53]:

Oh no, the documentation was handed over. Two vendors later, they— that handover was missed. And then it came back to me for a question that I could answer in a, in a 5-minute, you know, reading an old email and then running a SQL query to say, yes, still running as the same as when I implemented it.

John Byrne [00:44:14]:

But I don't know, you were still there. If you'd moved on now, they'd be in trouble.

Dante Healy [00:44:20]:

Let's not say that. But yeah, it's cool. It's cool. I mean, to be fair, that's the other thing with documentation. You can have the documentation, doesn't mean it's going to be accepted by the person or even read. You know, how many, how many BAU teams just rely on the experts still being around within the organization, even if you wrote perfect documentation? If the person who's taking it over doesn't bother to read it because it's not in their DNA and they're just used to asking other people for help every time they have a problem, then, you know, that's another issue. But you can't mitigate everything. You just have to try and remove that learned helplessness.

John Byrne [00:45:04]:

And you do have as well, it's within the system, it's within the culture of the organization. Because, like, you know, there are times where I don't have to do too much documentation. As I said, I mentioned earlier, sometimes you do help them, you know, update our policies and stuff like that. And I, you know, trying to update a policy and you don't know where it is, what the policies are, because they're all over the place. They were in different, you know, depending on who created them. Where they put it. And, you know, if that's the culture of the organization, they don't have a proper filing system, something you can't find it, you know, regardless of what type of documentation you're talking about. Or even like, I think we've discussed it previously when we were discussing lessons learned type of things, that the lessons learned are filed, you know, you'd have to take about 3 or 4 months to go through every file structure in the place.

John Byrne [00:46:03]:

Folder structure in the place to find the lessons learned because they aren't putting them in a central location where they can be searched and accessed by a new project manager coming in. And that's so, that's even where the type of documentation that I'd be doing, project documentation, that's a big weakness that yes, you know, you can do great documentation, but then it's just filed away and lost that, you know, nobody knows. So then when somebody comes along in 2 years' time and there's a problem with the system, they think, well, how was it configured? How was it set up? Oh, that's in the project documentation. Well, where is it? Oh, don't know.

Dante Healy [00:46:40]:

Yeah. Oh, I misplaced it. There was a link someone shared with me and I forgot to file it.

John Byrne [00:46:45]:

Yeah, that's it. Okay. Well then search. What are we searching for? I don't know. You know what I mean?

Dante Healy [00:46:51]:

Oh, that link was in their C drive. Oh, and we, we wiped their drive when they handed in their hardware.

John Byrne [00:46:59]:

That's it.

Dante Healy [00:47:00]:

Or, you know, remove their account and now there's no cloud storage there.

John Byrne [00:47:05]:

Yeah.

Dante Healy [00:47:05]:

What was effectively stored there has disappeared years ago.

John Byrne [00:47:10]:

Or the new one now, we're using channels in Teams and the channel has an owner and, you know, you make sure everybody— there's at least 2 owners for every channel, but that's only 2 people to go. Yeah, you know, and it's very like— and I'm sure we're not the, the only place like, um, where I was a co-owner and the owner is gone, so I've gone in now and I've made sure that there's at least one other owner or not, not the only owner left, you know. And I think— but that was just left on to me. There was no, um, clear policy that this is how it's done, you know. And I'm sure that happens in a lot of places. So it looks good when you've done it, you've got all the files up and that, but then the owner has left, which means nobody can add a new person to it. Nobody can edit it. Eventually all the people who have access to it move on or leave or whatever, and then nobody has access to it anymore.

John Byrne [00:48:05]:

It's just gone.

Dante Healy [00:48:06]:

You can't access it. But surely there should be a system admin that defaults to override. Unless that system admin leaves and no one replaces them.

John Byrne [00:48:14]:

Then there, that could be it. But that, but that's what you're relying on then, you know, system admin, but then you're coming in as a project manager. And you want to look at the old project lessons learned or whatever. You won't even have access to know that you haven't got it. So you won't even be able to see it to know you haven't got access to it. If you know what I mean. So you don't know to go to the system admin and say, oh, look, I need access to that because you don't know it's there. So that, that is a big thing as well.

John Byrne [00:48:40]:

I think for documentation is, you know, anybody who's doing it, come up with all the great documentation in the world that you want, but make sure there is some kind of a central folder structure that that documentation can be put into, can be searched, can be accessed by anyone who needs it. And not necessarily anybody in the organization, but obviously the, you know, role-based security protocols and that. But any other project manager who comes in may need to look back on that, whether they're, even if they're not doing a project on your system. Lessons learned is often a cultural thing across the organization, not just for your one project.

Dante Healy [00:49:17]:

But I mean, ultimately, that's why best practice is to have a public repository of all the documentation. Most people set up SharePoint sites, right?

John Byrne [00:49:27]:

Yeah, but that's what we have. But as I said, SharePoint and the Teams channels now, which seems to be kind of merging and becoming one.

Dante Healy [00:49:35]:

Yeah, you know, you create a Teams channel, it automatically creates a SharePoint site by default once you load files into it. Yeah.

John Byrne [00:49:42]:

Yeah, but you do then have that issue that all these themes channels, they're not, there's not a central, where's the central repository? They're all kind of still, it's going to be very difficult for somebody in the future to search up on our project because our project is running themes channel. Yeah. Hell, I mean, it's become problematic for me at times because there are 3 different themes channels depending on, because you couldn't, Maybe you can, and somebody else who's listening says, yeah, it's easy to do, but there are a lot of things.

Dante Healy [00:50:13]:

Yeah, we've configured this, we've federated it.

John Byrne [00:50:16]:

We, we, we, we can't give an external person access to an internal.

Dante Healy [00:50:22]:

Oh yeah, I hate that. I hate that security protocol. You have a load of external vendors and because they set up, because they're on a Teams chat, you can't upload documents.

John Byrne [00:50:34]:

Yeah. So we, so we ended up with, we have a channel for the internal thing with documents, but then we set up a channel that allows external people in. I mean, documents there, but the reality is you need all the documents are one project, but we've got them in two different channels. So that's going to be very, you know, I, I'm aware of what's in what thing now and then the people working, but like in two years time, if somebody has to go back and check something, which channel are they checking? You know, they look in the wrong channel and they say, well, that document isn't there. They never did it.

Dante Healy [00:51:04]:

What you need is one wiki on the main channel and then you link it to the secondary channel and say, look, we have two channels, one for external people, one for our internal people, and here's what you can find where. And again, it comes back to that indexing and searching, making things searchable by title or topic or whatever.

John Byrne [00:51:28]:

But, but, you know, they're, they're all, you know, we, we kind of at the start we were discussing putting together the doc, the different types of documentation, what you think of a document and what I think of and all that, and who'd be responsible for doing it, will they, blah, blah, blah. But, you know, as you kind of mentioned then, you can put together the best document in the world, but if people won't read it, and now it's kind of, you can put together the best document in the world and you can have all the people in the world who want to read it, but if they can't bloody find the thing, it does no good.

Dante Healy [00:51:59]:

Oh man, it's coming back to basics, right? Yeah. So thanks. I think, I think this was a good, good conversation. Wasn't expecting that on such a dry topic, but yeah, it was fun. Any parting thoughts, John, from this conversation?

John Byrne [00:52:20]:

I think the key thing is, like, one of the things that came in is make sure you know what documentation is needed. Because like I would never have even considered what you were like when we started the conversation. I knew we were going to be talking about documentation and then you completely threw me by mentioning documents that never even would occur to me because I just, the projects that I do don't need them. But I suppose it does kind of show though, pay attention when you start a project that just because you've never had to do a particular type of document before, make sure you know what documents are needed for this project, this new one that you're doing, because You know, no matter how experienced you are, you might get thrown for a loop there because that is something that would have been a weakness now of mine if I'd have ever gone in and started doing one of your types of projects. It probably wouldn't have occurred to me that, oh, I need to do a completely different type of documentation now. I need to worry about and pay attention to.

Dante Healy [00:53:09]:

Yeah, thanks, John. And the same with me. I mean, thinking about what you encounter in your types of projects, I wonder if I'm overdoing it because You know, we, we anticipate that we'll get a whole load of questions when we pass our project over to BAU, so the Operations Support Team, which is a separate team, and they ask for everything. That being said, my point would be is that a lot of the time you can prepare all the best documentation in the world, you hand it over to the wrong person, they're never going to use it anyway, no matter how good and well thought and well structured it is. But at the same time, if you do get people coming back to you when you know you've already documented it, point them back to the documentation. That's assuming it's findable, because again, you can, you can act like a narcotic dealer and just get them so addicted to your support that you can make yourself irreplaceable. But you don't want to do that. Because it's always going to come back to you.

John Byrne [00:54:19]:

And there's downsides, you know, I know there's a lot of people think, oh, to be irreplaceable is brilliant, it means your job is secure, but there are downsides to it that I've seen with other—

Dante Healy [00:54:27]:

Well, if you want to, if you want to get promoted, that's not a good play at all.

John Byrne [00:54:32]:

Exactly, exactly. If you're, if you're irreplaceable, that means you are stuck where you are and you will never get to know your boss, will make sure of that because you are irreplaceable.

Dante Healy [00:54:42]:

Exactly. Exactly. Okay, well, with that in mind, John, thank you very much. Great, great, great insights. And yeah, we'll think about the next topic. There's quite a lot to unpack here.

John Byrne [00:54:57]:

Thank you, Dante.