Meet Jill. Jill is a web developer. She likes her job. However, Jill can see some additional tasks on her project that need doing. They're things like planning, prioritization, and communication with her boss and with her client about when the project will be done.
So Jill takes some initiative and handles those tasks. She learns a little about spreadsheets along the way, and her boss notices she's pretty good with clients.
This happens a few times more, and suddenly Jill is asked to manage the next project she's assigned to. A little time goes by and she's got a different job title and different expectations to go along with it.
This is a pretty common thing. As a designer, developer, and especially as a freelancer, you spot things that need doing. Before you know it, you're doing a different job, and you've never had an ounce of training. The best you can do is read a few blog posts about scrum and off you go!
Getting up to speed
As an accidental project manager (PM), you’ll have to exercise a different set of muscles to succeed in your new role. There are tricks and tactics that you’ll need that don’t always come naturally.
For example, most of my early PM failures came because I thought and acted like a developer who was out to solve problems for the client. That’s a great perspective, but has to be tempered with regard for the scope of the project. A PM needs to be able to step back, recognize an idea’s worth, and still say “We can’t do that”, for reasons of time or budget.
It can take time to build those new ways of thinking. Even worse, accidental project managers don't benefit much from the training that's available. I’ve found little value in the certifications and large volumes of information that exist for PMs—the Project Management Body of Knowledge (PMBOK) and the related Project Management Professional (PMP) certification are a prime example, but there are other certifications as well.
It’s really a question of scale: As an accidental project manager, a certification like the PMP is a terrible fit for where you're at, because you manage small-to-medium digital projects. Unless you’re building a skyscraper, you don't need 47 different processes and 71 distinct documents to manage things—you just need the right tools, applied in the right way.
In order to help fill that knowledge gap for accidental project managers, I’ve decided to start a series. In the future, I plan to post about scope control, measuring and reporting progress, and other topics that are important to PMs, but for now we’re going to cover just one: Risk Management.
Defining Risk
If you were looking at the PMBOK, you'd see risk defined like this:
an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, or quality.
I fell asleep just pasting that into this post...I can hear you snoring as well, so we'll need a better definition. How about this:
Risk is a way of talking about uncertainty in your project—things that could affect your project that you're not sure about.
I like that better – it's more human, at the very least.
How to manage risks
- Identify uncertainties, especially at kickoff or in transitions between project phases
- Assess those risks for possible impact, likelihood, and relative priority
- Plan responses to the risks that you feel are likely or high-priority
- Monitor and address risks as the project progresses
Essentially, you should be brainstorming with the following questions:
- What am I worried about? (risk identification)
- Why am I worried about that? (possible impact)
- How worried am I that this could happen? (likelihood/priority)
- What can I control about this? (mitigation strategies)
- What should I do if this thing actually happens? (response planning)
But that doesn't feel good...
You've nailed it. All those questions are great to ask – and better yet, talk about with your team and your client. The tricky part is that all this requires honesty. You have to be honest with yourself about what could happen, and this may lead you to realize some difficult things, possibly about yourself, the team you're working with, or the client you're working for. I'm going to go out on a limb and say that most project problems are not technical.
Brainstorming and being honest with yourself might lead you to truths like "I don't trust my client to deal with me honestly", or "My development team is unreliable.” That's hard stuff, and requires delicate handling.
In the end, the underlying reasons for risks are the reasons your project will fail, so you want to handle them as openly as possible. Letting that stuff go unattended is bad news. Get it out where you can do something about it.
Getting risk management into your routine
Risks can be identified throughout a project, but it’s often best to try and spot them right away during a kickoff. Any time you or your team is uncomfortable with something—a development task, a stakeholder, or whatever it may be—you should write it down. Even if you're not sure what to write down exactly, it's worthwhile to discuss with the team and see if you can spot what’s making you uncomfortable.
As the project progresses, you’ll want to communicate weekly with the client about risks you’re seeing, make plans to address them, and highlight items that are becoming more and more likely from week to week.That might take the form of a brief meeting, or an email summary calling out important points in a shared document that the client has access to.
However you communicate risks to your client, you'll want to track them someplace. You can do it in a simple list of items to discuss together or with your client, or you can use a more formal document called a risk log.
The Risk Log
You can track risks anywhere you want, but if you're feeling formal, it's common to keep them in a log that you can update and refer to throughout the project.
One thing to know is that risks are often stated in ‘condition > cause > consequence’ format. The format is loosely structured like this:
“There is a risk that …{something will happen}… caused by …{some condition}… resulting in …{some outcome}.”
Then for each risk, the log lets you:
- track scores for likelihood and probable impact (on a 1-5 scale),
- identify warning signs or dates for when action is needed add action plans for each risk in the log.
- assign a responsible person
I've created a sample risk log for you to copy and modify as needed. If you don't think your project needs this kind of formality, it's possible to keep a simple running list of items to raise and discuss with the team. Nevertheless, seeing the slightly more formal version can help formulate what kind of tracking and tactics are available for the risks your project is facing.
Really comprehensive risk logs can also contain things like financial cost tracking, but that's rarely been a useful measure in my experience. Even big web projects rarely need that kind of tracking.
Common Risk Areas
Physicist Nils Bohr said: "An expert is a man who has made all the mistakes which can be made, in a narrow field." As an accidental project manager, you may lack the rich history of failures that might help you spot an impending risk. To help you figure out what risks you should be managing, here are a bunch of places to look:
When planning your project, watch out when:
- Tasks exist that rely on the completion of other work before they can begin
- Tasks exist that none of the project team has ever done before
- You are required to use unfamiliar technologies
- Tasks involve third parties or external vendors
- Multiple systems have to interact, as in the case of api integration or data migration
- Key decision makers are not available
- Decisions involve more than one department/team
- Resources/staff exist that are outside your direct control
- You have to plan a task based on assumption rather than fact
When interacting with people, watch out for:
- People who are worried about loss of their job
- People who will require retraining
- People that may be moved to a different department/team
- People that are being forced to commit resources to the project unwillingly
- People who fear loss of control over a function or resources
- People forced to do their job in a different way than they're used to
- People that are handling new or additional job functions (perhaps that's you?)
- People who will have to use a new technology
Many of the people-oriented risks in the list above fall under the heading of ‘Change is hard’. This is especially true with folks on a client or external team where a new project introduces changes to the way they do business. If you're providing services to a client, you may bear some of the brunt of those change-related stressors.
Change-related risks aren’t limited to people outside your team —sometimes the developers, designers or other folks working directly with you have the same concerns. Wherever you find it, risk management is often about taking good care of people in the middle of change.
Organizational risk
It’s probably also worth mentioning that risks can also arise from organizational change outside your immediate control. Corporate restructuring and changes in leadership can impact your project, and politics between different business units are frequently a source of challenges.
There may not be a ton you can do about these kinds of risks, but identifying them and understanding how they affect your project can make a big difference in how you communicate about things.
So, accidental project manager, go forth and manage your risk! Take some time and think through what you’re uncomfortable or worried about. Be circumspect, ask yourself a lot of ‘why’ questions, and then communicate about it. You’ll be glad you did.