One of the most difficult things in deploying a methodology is the buy-in from both your team and from leadership. You can have a great set of standards, documents and processes but it will be of little to no value if nobody is willing to use it. In this article I’ll talk a little bit about what you can do to help get your methodology sold to your organization.
Depending on how repeatable your projects are will help drive what parts of your methodology can be standardized versus what needs to be defined on a project by project basis. For example, a software shop that implements COTS solutions will likely have a much more repeatable set of delivery steps than a custom software shop that focuses more on designing new things with every project. That being said there are common elements to both scenarios that fit well within the framework of a methodology.
Having a methodology doesn’t mean you need to have checklists for every single task you do. We hire smart people and pay them good salaries – leverage that to your advantage. By having a methodology in place, it gives your teams the framework from which they can work within. Depending on how prescriptive you want your delivery to be will also dictate how much freedom your teams have to ‘do it their way’ within your framework. I’ve often leaned to giving teams a framework with an expected finish line (ex. Defined requirements, project plans that address common milestones, etc.) tends to yield better results since teams feel a greater sense of autonomy when doing their job. In the knowledge industry there’s not many more de-motivating tasks than having to complete something so prescriptive (that you didn’t prescribe!) that it takes all forms of creativity out of the picture. Communicate expectations and provide roadblock-clearing assistance but let your teams do what they are paid to do – deliver results!
Methodologies are great to help reduce the amount of ambiguity for a project or help quickly onboard and educate new team members. But they are also great for measuring projects. Having a methodology allows leadership to measure different projects in an ‘apples-to-apples’ type comparison. If your C-Suite could see a list of common milestones across all projects and then see each individual project’s measure, they can very quickly and accurately tell which projects are on track and which ones may need some intervention. Leadership often does not have time for detailed status reports on all projects, each of which may have their own nuances and special details. They need to know what’s happening across the board in very short order. If a couple of slides can be shown to them that illustrate the overall project health of the company’s portfolio of projects, you will have some very engaged leaders wanting to know why the good ones are succeeding and what can be done to help the lagging projects.
Building a methodology is not easy. Deploying one is even tougher. As with anything that we try to persuade others to use, you need to use the WIIFM (What’s In It For Me?) approach. Show the teams why having a methodology will help them do their jobs better and faster and easier but still giving them the creative license to think of new ways to achieve their goals. Show your leadership why having consistent measures of projects across the board will help save them time and money by focusing on having a solid and healthy portfolio or projects. While building and deploying a methodology are difficult at best but having a deep methodology that you can use time and again is a great payoff!
It’s important to define the difference between developing a methodology and standardizing. A methodology is a systematic way of delivery. It is your core set of processes for building and delivering a project to your customers. Standardizing is a way of defining what you will term as acceptable.
Want to know how we can help you and your team? Let's talk!