My Project Management Framework for Knowledge Workers

A framework is a high level view of something that shows how the parts fit together. It is not a set of detailed instructions. My hope is that you may find some benefit in this very general framework. This will not put you on the cutting edge of the latest in Scrum or whatever (that's about 30 years old anyways!).

Neither do I see value in offering some complex, gargantuan set of intricate instructions like this and intend for you to apply it in your daily work. Good grief!

Rather, these simple sets of rules and steps (I think 31 in total) are there to address the more critical aspects of any project at any scale and complexity.

I am just conveying the most vanilla of instructions to keep in mind while you face the challenge of transforming instructions into knowledge work.

That's my hope at least. I've needed to do this for myself, so maybe someone else can benefit.

Here's how I understand a project:

Task Management

How do you eat an elephant? One bite at a time. So too with projects. Tasks are the basic unit of any project. However you break down your work, however it gets segregated and allocated, there will be tasks.

I'm not going to define a task for you, but I suggest that you tie them directly to your deliverables.

It's necessary to maintain a general view of tasks because each organization / project / team will have their own perspective on what tasks are and how to manage them.

But no matter the scheme, no matter the app, or the foibles you have to work around, every task will exist across these 9 domains:

The 9 Domains of Task Management

Why these 9 boxes and why are they arranged in this manner? You can think of these as capturing different aspects of what a task is depending on if you are looking at the data, information or knowledge and whether you want to know what, how, or why you are doing it. If you can cover all of that, you've got a good chance of not overlooking anything.

Let's see how this matrix can be applied to knowledge workers:

• Your "Work" is a "How" applied to the "Information".
• You "Decide" because you "Know" "Why". Etcetera.

When projects are sufficiently complex you should log each of your activities in these domains:

At the end of the day all knowledge work is hard. It's even harder when we need to cooperate and communicate with others. Lots of us muddle through. But some self discipline and team discipline in this area will go a long way to keeping on top of the chaos. All of which will be for naught if we don't keep our documents in order!

Filing and Information Management

The next area to cover is filing and information management. The worst thing you can do is not have any definition or consistency around version history for controlled documents. "Rev A. This one. revised. Approved. Reapproved V2. March 2"

If you are stuck in the confines of a filing management software, just accept that most of the inefficiencies are there on purpose to place controls over changes and approvals. It's not supposed to be as easy as you just making files and replacing them. Whenever others will rely upon your work there should be an explicit set of instructions that lets others know the status of your work. Only approved documents should used.

9 Rules for Filing Management

1. File regularly (revision, references, redlines, checkprints, emails, downloads, and other feedback)
2. Whatever your folder structure, create subfolders only when they are needed. Avoid empty folders.
3. All deliverables are Working Items. Any other document may also be a Working Item if others will rely upon it.
4. Maintain version control of working items
5. Checkprints are a snapshot in time of working items to be shared with others for their feedback, but not as an approved document.
6. Keep track of feedback received. Save this in a Bluebeam session, or as marked up documents in a folder, etc.
7. Only send “Approved” documents to other disciplines, the client, or a 3rd party (and for professional engineers be aware of authentication standards)
8. Formally issue deliverables with a transmittal and keep a log of all transmittals.
9. All working items have this structure:

• References (subcategories: Templates, Checklists, Standards, Technical, etc.)
• Working (subcategories:??Superseded & Checkprints)
• Checking (subcategories: From &?To)
• Approved (subcategory: Obsolete)

There's much, much more to be said about this. For instance, I have not talked about how to do version control. Nor have I said anything about how to name documents. And I don't want to get within 100 feet of the topic of what's the best folder structure to use. All of those variations have pros and cons. The best advice I ever received was that whatever you choose, make it something that everyone can follow consistently.

One more thing to add. References. File your references. File them in multiple locations. File them as you receive them. File them wherever they're needed. You should file sufficient references so that a complete check package can be made easily, when the time comes. Do it as you go and it won't be difficult to piece together at the end.

So these 9 rules are intended in the spirit of simple but essential rules that everyone can follow consistently. If you are consistent you'll be able to find things easier and you won't generate uncertainty about the reliability of information (with all the problems that stem from it).

Problem Solving

When you are planning your work you should be gathering all your sources of information and ensuring you have all the necessary resources to complete your task. Use these steps as a guide to bring to your attention what areas you need to address. Since we've had 9 Domains of Task Management, and 9 Rules for Filing Management, I may as well continue in that vein:

9 steps in problem solving

1. Problem definition (Scope)
2. Assumptions
3. Limitations
4. Methodology
5. Sources of information (References)
6. Analysis
7. Conclusion
8. Recommendations
9. Documentation

This is probably very close to something that many of you would have learned in science class for documenting your lab work. Well, to me, that's not surprising because from a certain perspective all knowledge workers are essentially making lab reports. We are taking in data, obtaining information with reference to standards or objectives, thinking about it, making a decision, and producing something as a result, typically in the form of documentation (we aren't making cars or painting murals, we make PDFs).

When decisions are critical, be very clear in addressing each of these and including them in the documentation step.

Decisions

Life is a series of decisions and any one of them could lead us down a different path. Even when we have very clear and distinctive criteria there is some value judgment that goes beyond any simple A+B+C procedure. And there are ENDLESS volumes of books and podcasts offering you advice on how to make better decisions. I don't pretend to be your guru.

We all make decisions for essentially inscrutable reasons. God knows why I chose to jump that little extra to try and score the basket, when I knew was pushing my limits. Oh well, ACLs are overrated ;)

There is, however, a set of 4 dialectics that I want to offer as a possible set of tensions to grapple with. Decisions are murky, but if we can orient ourselves along these 4 dialectical poles, then I think we will usually make better decisions according to our own criteria. You'll know best:

Small Kindnesses

You may have noticed I used artificial intelligence throughout this post to create the images you see. I have also used ChatGPT in the planning and preparation of this post. All the words were written by me, but I used AI extensively and I have even more comprehensive plans that I'm looking forward to sharing here.

The more I deal with these bots, the more I appreciate you people. We're pretty special, us humans. Does all this stuff we're striving after just end in AI and robots? Well, if it must, let's be kind to each other along the way.

And I've found in my career managing teams that you get higher performance over the long run using values alignment, clear expectations, and some kindness in understanding each person's limitations. That way, when I inevitably screw up, you might show some kindness to me in return. We're all on the same team, human :)

Thanks for your attention. I hope something here benefits you!