How do I make sure governance doesn't keep my projects from missing their deadlines?
How many times have you heard a project manager say this? "We don't have time for an architecture review. If I have to put together all of this information for your review, my schedule is going to slip!" Personally, I've never seen a report that states the average delay caused by project governance efforts, but there's no doubting that this perception exists. Let's face it, anything that is outside the direct control of the project manager will be perceived as something that will put the schedule at risk. Rather than argue over whether that perception is justified, we should instead be asking the question, "How can I make my governance processes effective and efficient?"
We're frequently behind the eight ball when it comes to project governance. Most organizations are staffed to deliver solutions, and the amount of time available for overhead activities like governance is few and far between. If your staff can only carve out an hour a week for oversight activities, how many projects can they realistically oversee? A frequent approach is to have a standing time allocated each week to perform architecture reviews. How many of the following sound familiar to you? First, project teams scramble to get the materials available before the review and are lucky if they are there by close of business the day before the review. Second, even if the materials were available, the reviewers are likely busy doing other activities, so they don't bother to look at the materials in advance. When the meeting arrives, the 30 minutes to 60 minutes allocated for the review are spent bringing everyone up to speed on what the project is trying to accomplish, and then the time runs out and the project is forced to wait another week to complete the review. Oh, and by the way, the project is far into development and has only scheduled the review to make sure they don't get a black mark on their project report card.
Whether your governance processes are at that extreme or not, there's probably room for improvement wherever you are at. So how do we make this process more efficient? Here are some helpful hints.
Hint 1: Document your standards and guidelines. This may seem obvious, but there are many organizations that govern against undocumented standards and guidelines. If you don't have documented standards and guidelines, how can projects have any idea what compliance is? How can you ensure that your governance efforts will be consistent if you have different people performing reviews? If things aren't documented, the impact will show up in many places. Your staff will get pulled into more project activities due to their knowledge, thereby reducing their ability to work on other activities, includinggoverning other projects. The consistency of your governance efforts will be almost wholly dependent on the people involved, since each reviewer will govern by their own experiences and interests. Project delivery may be severely impacted since the governing team may make significant changes because expectations for the project team were not well communicated.
Hint 2: Be proactive. Having documented standards and guidelines is good, but if no one reads them, they aren't going to help much. Your staff needs to be aware of those standards and guidelines, and they need to be reminded of those guidelines on a regular basis. Are your standards and guidelines part of your onboarding process for your IT staff? What guidance do you give a project when it is formed? Are they pointed to appropriate guidance based on the project charter, or are they left to fend for themselves?
Hint 3: Focus your efforts. If you have limited staff, you may not have the resources to do a detailed review of every effort. You can optimize your efforts in a couple of ways. First, you can set up-front criteria to reduce the number of projects that undergo detailed reviews; for example, you may only review projects over a certain number of hours or a certain dollar amount. Second, you can have projects perform self-assessments via a checklist to get your reviewers focused on the things that really matter. A checklist can also allow you to minimize the number of reviewers needed, since it gives the reviewer explicit instructions on how to execute the review while also increasing the consistency of the reviews regardless of who executes them.
Hint 4: Be accountable. If you're asking the project team to provide deliverables a few days before the actual review, then your reviewers had better review those deliverables ahead of time and come prepared with comments and questions.
Hint 5: Govern deliverables that are already being created. Don't make a project team create special deliverables just for the governance effort. That's extra work that the project must do outside of trying to deliver the solution. If there's something that you need to see for the purposes of project governance, why isn't it needed for the actual solution documentation to begin with?
Hint 6: Govern your governance. Don't ever forget that the purpose of governance is not 100% compliance; the purpose of governance is to make sure that the decisions being made are going to deliver the solutions the business needs. If you are 100% compliant but you're not delivering things on time or you're not meeting other business objectives, then something about your governance needs to change.
Project governance doesn't have to be a negative experience at your company. With these hints, hopefully you can turn what many may see as a necessary evil into a valuable necessity.
Dig Deeper on Topics Archive
Related Q&A from Todd Biske
The emergence of the stack brings up an important question: Are app servers dead? Contributor Todd Biske examines the future of the app server in a ... Continue Reading
Everyone has a different viewpoint on SOA, but three key differences between SOA and microservices architectures can help you determine which is best... Continue Reading
Why do we need mircoservices architecture? How can we benefit from it? Continue Reading