I certified as a project manager several years ago. At the time, I figured it to be the best way to further my career. Turns out, I actually don’t do formal project management on the regular. So going through the rigmarole of keeping the certification up to date seemed like a futile and rather expensive endeavor.

We got people for that at NSCC. I appreciate them with my whole heart. Because, even though I have a fairly deep understanding of the practice, I absolutely loathe structured project management.

All that said, I do project management every darn day. And I love it.

Yes, I am rife with contradiction, but I’m a pretty nice guy if you get to know me. Most of the time.

Here’s how project management sits with me:

My favorite definition of a project is an endeavor of related activities that produces a desired outcome, product or result. Projects have a declared beginning and a defined end. There’s people, time and money invested. An accepted standard of quality is employed to ensure that the work is economic, efficient and effective.

There are better definitions, but let’s go with this one.

You can be efficient doing things right.

But to be effective, you have to also be

doing the right things.

There are all kinds of important things to consider when working on projects. The big one for me and where I see projects tank is a failure to gain consensus on a definition of done.This starts with good requirements gathering, continues with iterative review and refinement, and ends with an outcome everyone can live with.

The next big thing for project success is defining exactly who ‘everyone’ is. Who are the pigs and who are the chickens? Get that RACI diagram doped out ASAP.

Because NSCC is what it is, defining scope, done and stakeholders is often nigh on impossible. Or atleast a lot of work that peeps are not overly excited to do. Folks just want the work done.

I get it. Which is why I love that we have a Project Management Office and a Technology Governance Committee. At least these groups can wrestle the larger pieces of work into enterprise undertakings that will be successful.

Now, a lot of the work I do is operational in nature. I manage teams that do a lot of atomic and discrete break-fix or request-driven work. That’s why we have ITIL, ITSM and the Technology Service Desk. Totally works. And then there’s all the stuff in-between. The messy middle, if you will. The corner-of-the-desk project. Or if you’re habitual in not keeping good work-life balance, the corner-of-the-nightstand project.

For stuff that’s bigger than a service request and smaller than a bona fide project, we’re left to kinda figure it out on our own. It’s a bit of a dark art (read: science + experience) to determine when your service request is actually a ‘little-p’ project. It’s also an exercise in courage to recognize and admit that your ‘little-p’ project is actually an over-sized monster that needs the big guns to slay.

That came out a little more violent than I intended.

Sorry. Blame it on the coffee.

Anyhoo… This is where the agile project methodologies come in.

• You don’t have a definition of done.
• The scope is open-ended or organic or creative.
• You don’t have dedicated people or funds.

Once you’ve detected that you have an ‘operationally-resourced project’, you can do some things to make it better:

1. Gather your team. Keep it small. Keep it relevant.
2. Ask why this work is important.
3. Spend the time and define what done looks like.
4. Brainstorm out all the tasks.
5. Dump out all the rocks that might be in the way.
6. Ask: are these solvable problems?
7. Decide if the work is doable.

Take the time with your proto-project team to do this before you do any actual work. This is basic Idea Assessment work and you’d have to do it before pushing this forward to the Project Management Office. But it’s good practice anyway.

Do you still have a ‘little-p’ project?

Sorry to hear that– I mean– awesome!

• You have no clear funding envelop.
• You have no dedicated team.
• But you now have a workable scope and a team of (hopefully) like-minded folks.

Now you can start planning for realzies.

Next post:

I’ll go through the Agile framework, kanban boards and how to develop this kind of project into a plan using things called: product backlog, story points and sprints. After that, we’ll be in good shape to tackle Microsoft Planner and how to leverage that tool to get these impossible projects across the finish line.