In my last article in December 2020, we talked about the process of establishing a Project Management Office in city government. We talked about how we identified the need to implement a PMO, the difference between a project and a program and how a PMO is essential to managing the organizational portfolio. We also talked about the role of a PMO and the different types of PMOs we need to look at before choosing one that meets our needs. We then went on to talk about how managing a project/program in local government is different from managing one in a corporate setting followed by the process of building a PMO at the City of Syracuse.
Now that the PMO is set up and we have most of everything we need, we opened business which means we started taking on projects in compliance with the new project management model. For anyone who has worked in local governments, especially in small cities, you know that every person wears multiple hats irrespective of the role that they were hired for. This could be due to many reasons, common ones being unavailability of large pool of skilled resources and shortage of funds. When people start wearing multiple hats, the amount of work they take up also increases proportionally. So then, the question was how do we prevent or reduce burnout, inequitable distribution of work, and the feeling of not being able to give your 100% to any single task? The answer lies is efficient management of workflows, and managing the project intake based on your team’s capacity and skills.
Oh, that sounds easy! Not quite, this may seem simple, but there was a lot that had to be built before we even got here. In this blogpost, I’m going to take you through what it takes to build a project intake process that will give you control over what projects you take on, how many, and in what timeframe.
Note: This process was created for our needs and the type of work we do at city hall. It may look completely different based on your team’s work
Why do we need a project intake process?
Project intake is important because it gives greater control over how you take up work, more importantly it helps define the team’s portfolio by letting you decide what projects you want to work on. This is crucial in shaping the identity of the team. Here are some other reasons why we need it:
To create a central source of entry for all project/work requests( both internal and external)
To formally authorize projects
To track all work assignments and project ownership
To measure and document the team’s contribution in the organizational context
To ensure projects are prioritized efficiently and delivered on time with quality
To ensure fair distribution of work within the team
To use this as a diagnostic tool to identify resource gaps(skill, time, technology) and improve service
To define the need, conduct impact analysis, and identify trends/patterns in requests which can be used to design training programs and promote self-sufficiency within departments
What does an efficient project intake process look like( a.k.a. how do you know its working)?
Single ‘Front Door’. Ambiguity and shadow work gets eliminated
Clear roles and responsibilities for people involved in the intake process
Everyone in the organization knows how to submit a request, what information is needed, and how it will be used
Clarity around process ownership, so that there is accountability and transparency. Usually, the PMO owns this process
Clear communication within the team and with external stakeholders
Established timelines for submitting requests. Which day of the week should they submit requests? Is there a standing meeting to review those submissions? Information is documented and shared across all parties
Regular audits and feedback to monitor the efficacy of the process
Identify success metrics based on process evaluation and visualize results. These can then be shared with stakeholders for continued buy-in
Process of building a project intake process:
Identify roles and responsibilities: The roles and responsibilities of each participant in the process need to determined, documented and communicated. Remember to go through this process with care because there is often a risk of dumping responsibilities on people without taking their opinions into consideration. Make sure everyone agrees with the roles and responsibilities assigned to them.
Define project and service request: Identifying what a project means to your team and what kind of projects you want to be involved in. This requires some definition of a project and a service request based on variables like time required to complete the request, scope of the request, and resources required. Based on the category the request falls under, you can decide if the request should go through the project intake process or not. If a request meets or exceeds the thresholds on the variables, it is considered a project. For example, if a request can be completed by one person, in eight hours, affects only a handful of users, and does not carry an external cost, we consider that a service request, not a project. Service requests go through a different evaluation process since they don’t take up as much time and resources as a project.
Align and prioritize project requests: Once you categorize requests, you need to determine if the request is aligned with team and/or organizational goals. The idea being that projects which have a stronger alignment to these goals would be considered ahead of those that are somewhat aligned. Project requests with no alignment are parked (i.e. the request is a good idea, but it's just not the right time for it) or rejected. This prioritization process helps when there are more project requests than there is capacity on the team.
How to calculate alignment?: Once you identify the goals of your team and/or organization, you can assign weights to the goals in order of importance. The project requests are evaluated against these weighted goals which should give you a score. This score can be represented as a raw number or a percentage. In either case, the bigger the number, the stronger the alignment and higher the value. Value may be monetary, but might also be intangibles like risk avoidance or process improvement.
There should be three levels of alignment when accepting projects/programs.
Portfolio alignment: All projects accepted must align with overall team/organizational goals and produce considerable benefits to the end users (city residents/city employees)
Program alignment: All projects within a broader program must show justification for their creation. Breaking down programs into too many projects where unnecessary can lead to inefficiencies and bottlenecks
Project alignment: Ensure individual initiatives serve overall goals and objectives of the project and are implemented according to the framework
4. Project Evaluation and decision making: Once you have all the above ready, you can start evaluating your project requests based on the process you’ve established. Although all this seems like a lot of effort, it is necessary to make sure that the project decisions are unbiased, free from individual preferences, and variable factors. Below is an example of our evaluation process:
You can see that every project is evaluated against the same set of variables which makes the decisions consistent and reliable. It is undisputable that there will be exceptions and emergencies, but this process is a standard that will keep us accountable and transparent at all other times.
5. Communicate project decisions: Decide how, when, and what will be shared for each of these:
Project acceptance, rejection, and request for additional information
Determine SLAs for request evaluation and decision making
Who will review the requests?
Which day of the week will the requests be reviewed?
How often will they be reviewed?
How and when will the updates be shared?
By when will the decision be taken?
6. Conduct usability testing and take regular feedback: No matter how well-designed a process is, it is ineffective if it does not do the job it is intended to do. To make sure the process you built is performing well, conduct usability testing in the initial days where you ask requestors to fill the intake form in front of you and make a note of all things good, bad, and challenging. Use this feedback to continuously improve your process. Remember that every time you make considerable changes or improvements to your process, you have to repeat the usability testing.
Artifacts/Outputs of this process:
An intake form that everyone is expected to use: This helps control the flow of project requests, and automatically creates a record of the request, who placed it, and basic information about it.
Process Map: Process maps like these make it easier for people to follow your model. It has been repeatedly proven that pictures convey information more effectively than words.
3. A tutorial on what people need to know before filling out the intake form and how to fill the form: You can use this to set expectations, describe the context, what you are looking for from the form, and clarify any questions that may seem tricky at first glance. Remember that people might not have a fully developed idea while submitting a request or submit too much information to increase the chances of approval. Helping them understand what they need to submit and how it will be used will make it easier for them to fill the form.
Last but not the least, a list of your areas of expertise or portfolio: The most important part of this process is identifying your team and/or organization’s service offering or portfolio. This should talk about what your team is best at doing. Think of it this way, you are offering your services to other teams or departments and for them to know what to approach you for, they need to know what you bring to the table. Lack of this information will lead to project requests that you can’t work on or have nothing to do with and you will spend more time explaining why you can’t take on a certain project.
Wow, I know that was a lot! But I hope it helps! Also, before you go and probably start building your own version of this, remember that the secret to any successful process lies in its ability to be rigid and flexible based on the circumstances. It should provide enough support for you to implement sustainable, consistent, and reliable processes but also, at the same time, not be so rigid that it cannot accommodate any unknowns.