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!
Created in DALE3 by OpenAI

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

Created by Ryan Tufts, in Microsoft Word

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 ;)
Generated by DALE 3 from a prompt image created by Ryan Tufts

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:
Wording by Ryan Tufts, imagery created by Canva AI

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!