Why should you read this?
Starting a new project is often relegated to the routine, day to day, business as usual activity for many companies. Yet if you peel back the layers, inside that company, you can often find a maelstrom of expectations, risk, misunderstandings and emotion about the approach and, (if it exists) the project methodology. The reality is that starting a new project can be both exciting and frustrating, depending on an individual’s experience and understanding of company processes…and it all hinges on how well a company has established a strong, easy to follow, yet adaptive Project Methodology. This article aims to map out the reasons why a business should invest in this space, and offer a fast way to build a project methodology that is both useful and effective for your business.
Why you need a Project Methodology
Say your company has just given a new project, the green light. Everyone is nervously excited. It’s a big project – strategically important – and very high profile. There was a lot of talk leading up to the decision, that the company is on a “burning platform” and that urgent action is required. This project is the lynchpin in a larger portfolio of strategic ideas to build a new, stronger, less flammable platform. It’s a do-or-die situation for the company.
Finally she speaks. “I’m not sure you and your team are up to it…”
You walk into the boss’ office, and she stares at you hard for a whole minute, not saying a word. Finally she speaks. “I’m not going to give you the dross about how important this project is. You know all that. But I’m not sure you and your team are up to it”.
You’re at a loss for words. You thought back to the last few projects your team delivered…and wince internally.
“I don’t doubt your abilities”, she continues. “Individually you are strong, talented project managers. But together, you are all over the place. I see people pulling in different directions, constantly reinventing the wheel, rushing into delivering packages of work without a clear plan – and don’t get me started on governance!”
You take a deep breath. You knew this was coming, and you’d prepared for it. But before you can speak, she launches again. “This isn’t a project anymore. It’s a program – an entire portfolio of works. It’s much bigger than anything your team has handled before and we are hanging everything on getting it right. We need…”
“A better Project Methodology.” you finish for her, confidently. She studies you carefully, again. “Go on,” she says.
“I’ve been working on this for a while”, you say, “and I believe you are right. Our team is full of gun project managers. They know their stuff and can negotiate and lead with the best of them. But our company has never developed a project methodology that underpins the key principles from industry standards like ISO21500 and PMBoK, and brings them together in one place for everyone to follow. We have a few forms that are needed for financial accounting, and a general requirement for a project plan and a monthly report, but that’s about it. Nobody has any real guidance or direction in how to plan or deliver a project, who to consult along the way, when they should seek approvals for key stages… we don’t really have a proper framework to which we should be asking our project managers to conform.”
“Exactly!” she exclaims. “I need more confidence that we are following and complying with best practice, and that we are doing things in a consistently good way. We need something that ties in with our Quality Management System. Something that lets me focus on the big picture and gives me confidence that everyone is doing the right things at the right time – and that I will get called in when needed – but only when needed! I know things can change and perhaps go wrong, but I need to know we followed a strong process that helps minimise risks and manages expectations. I want less surprises, and better consistency.”
“I completely agree,” you say, a wry smile playing out for the first time since you walked in. “So…do you want to see it?”
Is that scenario a reality? Really?
In a word…yes. And no.
Companies, as you would expect, vary vastly in project management maturity. As a general rule, larger companies will already have some kind of system (but it will somehow be broken) and very small or new companies have nothing at all, and don’t even know if they need one.
Rare, however, is a company that has a solid project management system, underpinned by world class project methodology that they would trust with the scenario above. The truth is, companies are way more risk tolerant than they care to admit. It is perhaps an unconscious bias, where leaders prefer to imagine a more optimistic outcome, despite the lack of controls or guidance about how they wish to plan, manage and deliver projects. They pay less attention to building a system that works and trust more in individual experts to get the intended outcome. Unfortunately, the skills and effectiveness of even expert project managers can be hampered by a company’s lack of careful forethought about how to manage the complexity of risk, governance, stakeholders, communication, scope and budget management and more. At best, the expert does everything right while the rest of the company looks on in hushed awe – but at worst, they make up their own way, using their own experiences and lead the project team and stakeholders through a project that is confusing, and doesn’t meet the expectations or risk profile of the company as a whole.
In truth, it’s rarely the underlying project methodology that is broken – it’s the application at user level that fails. Good theory, laid out badly. Antiquated procedures that get gummed up in bureaucracy; an insistence on physical paper in a digital world, the use of email for variations and approvals, an excessive number of approvals without clear governance structures; no centralized data storage or version control; and my very favorite, a “one size fits all” mentality to processes, meaning a small project must go through excessive hoops to achieve compliance, relative to its risk and complexity.
Thankfully, there is a better way…
First, Let’s get back to basics. What is a ‘Project methodology”?
Essentially, it is a series of processes used by a business to guide users while reducing overall risk and increasing the likelihood of getting the right results when delivering projects. At a high level, it comes in a variety of flavours, all with cool names like “Prince 2, Agile, Waterfall, etc” …or it can be homegrown from scratch. Homegrown project methodologies can be highly effective if created properly, but, just like ‘home brewing’ beer, they still need to follow some general guidance or will likely end up with some foul tasting, possibly dangerous froth that defiantly isn’t beer! In Project Methodology terms, that general guidance comes from ISO21500: ‘Guidance on Project Management’, which was largely born out of the Project Management Body of Knowledge (PMBoK) Guide.
Your average Project Methodology sets apart ongoing processes (e.g. a maintenance regime or accounting procedures) from standalone projects. While many aspects of business meet the technical definition of a project (it has a start, a finish and a unique deliverable), e.g. planning your office Christmas party, rolling out a system software upgrade, introducing new business procedures or even recruiting a key staff member, we tend to focus on big ticket, “one-off” items that have a tangible degree of risk and benefits and might get you fired if you screw it up. The project methodology generally forms part of a company’s Quality Management System – the overarching procedures used to make sure the company can routinely deliver on its promises. Finally, most businesses adapt those initial high level methodologies into their own ‘Project Management System’ – often confusingly, also referred to as their ‘Project Methodology’.
We tend to use the following definition: “A Project Methodology is a tailored, bespoke series of processes, tools and templates, based loosely on the requirements of ISO21500, that together, govern how a business intends to consistently deliver projects.”
So, where do I get one?
Easy way: online, then customise it, at Yakkaplan. Hard way: build it from scratch, using broad consultation and a team of experts.
Best way: Use the Yakkaplan platform as a baseline and then experts and broad consultation to build a series of bespoke methodologies for your business!
Different industries have developed best practices and generalised project methodologies that reflect the nuances of those industries. IT projects have different requirements and processes to construction projects, which have different requirements to event management projects. Depending on your industry, your relevant industry associations may have resources available, or look at country specific or international project management associations (e.g. the Australian Institute of Project Management, or the International Project Management Association, or the Project Management Institute).
Despite industry differences, there will always be commonalities (e.g. they all draw upon the 10 Functional Knowledge Areas of PMBoK), but have enough differences to warrant the creation of different procedures. In addition, every company worth its salt will develop their own methodology, and protect it like the sacred IP that it is. For many companies, the project methodology is the “secret sauce” for how they differentiate from their competition – how they deliver better, faster, cheaper, etc.
If you plan to build it…
All project methodologies that a company develops should generally align with the industry standard (ISO21500), framework (PMBoK), or specific overarching methodologies (Prince 2, Agile, etc). While these guides lay out the who, why, what, how, etc. at a very high level, at a more practical level, people tend to need more detail and direct guidance.
For example, while PMBoK may discuss the need for “Stakeholder Management” and Prince 2 will give a procedure to conduct “Stakeholder Requirements Gathering”, the (company) project methodology will often be quite prescriptive and provide guidance and specific steps for meetings, documents, and approvals that are required to comply with their methodology. And note, these meetings, documents and approvals would be required for any project that the methodology is designed for, but the meetings will be with different people, the documents will use a common template but be very customised and the approvals require different people or roles.
Most importantly, a company’s project methodology should not be designed as ‘one size fits all’, but as ‘one size fits many’. It should be repeatable for a given type of project (within certain parameters) but should the project fall outside those parameters, it would revert to using a different project methodology.
These parameters are often classified by size, scope, value, complexity, risk, etc., so that a project with a $50k budget need only follow a lightweight series of steps and approvals to ensure a quality outcome relative to the risk of the project – there is no point spending more money on procedural stuff than actual project deliverables – and a $500 million project has a very robust and structured set of requirements that reflect and reduce the risk of failure.
This all sounds hard. What’s the easy way to build my own Project Methodology?
Of course! You wouldn’t be a good project manager if you didn’t know to look for a short cut!
Given most businesses guard their project methodology quite carefully and enforce various legal IP protections, simply copying from your next door neighbor is generally hard…and pointless. Each business is normally different enough to warrant their own version anyway.
The following approach, however, is one way to get off the ground quickly. It might still take a bit of time – but investing in this part of your business is as important as hiring good people, so the sage advice is to resist the urge to skimp.
Here’s the fast way:
- Identify and make a list of the kinds of projects that your business routinely delivers.
- Classify them according to whatever makes sense. Use multiple classifications per project – e.g. client type, industry, budget, complexity, risk.
- Rationalise, or ‘chunk up’ your classifications until you have three broad groupings that cover 90% of projects you are likely to deliver – that you could generally call “(1) small/fast/cheap/simple, (2) medium, (3) big/high risk/expensive/complex”.
- Reclassify each of your projects into one of those classifications – and make it a standard operating procedure to classify new projects this way.
- Review Yakkaplan’s standard project workflows to determine which ones are most relevant for your categories. (Yakkaplan has different procedures for generic “Simple, Medium, and Complex” projects, out of the box, and coming soon are different workflows for tailored for different industries.
- Create an account with Yakkaplan.
- Create your first project and select the relevant workflow for that project. (Each workflow comes with all of the necessary document templates needed to fulfill the workflow).
- Assign team members to your project and follow the existing workflow, or customise it to your specific business requirements and save it as a new workflow template that you can reuse over again.
- Invite experts to review or ratify that your customised workflow, and continue to improve until it is efficient and easy to follow.
- Click “Start Project” to use your project methodology and all of the time saving and risk reducing automation that comes with!
If you want help with any of this, contact us and we can help you through the entire process!
So…What are your next steps?
If you want to get started now, head over to Yakkaplan and start a Free Trial.
If you want to see what Yakkaplan’s Workflows look like, you can see them here.
Finally, if you thought this article was useful, please leave a comment below or share the love!
Happy Project Methodology building!