Recently a friend asked me for help:

„We have to prepare a lot of documents for a customer over the next couple of months. We do some preparations, then the customer has to check and approve, we do some clean ups, fill in some details and hand it over to the project lead of the customer. He will sign and publish it in their ECM.

My boss wants control, the customer wants to know where we are. My boss wants me to create a schedule for every document incl. exact forecasts and tracking in MS Project. I am already quite busy and can’t afford this overhead. What should I do?“

After all this is a typical mix of workload and interests likely to happen in a lot of projects.

What would you suggest ?

Before continuing to read you might want to take a minute and think about how you would proceed to find a suitable answer.

My solution was to follow a simplified project management strategy:



There are 3 main stakeholders involved

  • my friend and his team
  • his company represented by his supervisor
  • the customer represented by the project lead and various departments

Interests of the team

  • wants to get work done.
  • needs tool to understand project status and manage workload.
  • afraid of management control execution.
  • protection against possible claims by customer and own company.

Interests of the company

  • execute control when necessary.
  • sell status to customer.
  • detect chances for additional claiming.
  • defend possible claims of the customer.
  • detect excessive workloads and backlogs.
  • detect possibilities to reduce resources at times of low workload.

Interests of the customer

  • project maturity: what is done and what needs still to be done.
  • detect backlogs to take appropriate measures.
  • secure claims in case things go wrong.


Risks from the team’s point of view


  • excessive documentation prevents easy project overview.
  • excessive fixed planing prevents flexibility.
  • excessive scheduling. Every change of schedule needs to be discussed and keeps people from work.
  • waiting for the customer to prepare, approve, sign and publish a document has a strong influence beyond control of the team. Backlogs will happen.
  • undocumented backlogs caused by the customer will lead to claims from the customer against the team.
  • undocumented backlogs caused by the customer prevent possible claims against the customer when the project takes longer than expected.
  • undocumented backlogs prevent requests for additional resources when things take longer than expected.
  • when backlogs happen without known measures escalation is very likely.
  • scope changes (like unexpected additional documents to be created) might add to the workload and constrain resources.


  • communicate as little as possible and as much as necessary.
  • be aware that you are partly in a sales situation and not solving a technical problem.
  • use a tool which
    • helps you to get an overview.
    • documents backlogs caused by the customer.
    • contains measures to be taken if backlogs happen.
    • contains an automatically generated public summary.
    • except the summary everything has to be considered internal and non disclosure.
    • contains change management. Scope changes have to be agreed upon by your customer and your supervisor. And at project closure you might need to understand why a change happened for lessons learned documentation.


work breakdown structure

When creating your tool you need an understanding of your process. You have to know each state your document can take. Your internal documentation should track when it enters that state, when you are expecting it to move to the next one and when this move actually happened.

In our example above there are 7 main states

  • waiting
  • drafting
  • checking and approval by customer
  • detailing
  • hand over to customer’s project lead
  • signed by cutomer’s project lead
  • published in ECM

The first one needs no documentation because any document is in that state at start of project already. It automatically leaves it when drafting starts so documenting drafting is fully sufficient.

From point of view of the project team the last two states are out of scope. There are no tasks to be done after a document is handed over to the customer’s project lead. But there is a chance that the customer wants to have some of the post processing to be included into the tracking (at an extra charge, of course…) as it was the case with my friend from the example above. His customer wanted the publishing date to the ECM to be included.

So this results in a reduced set of states:

  • drafting
  • checking and approval by customer
  • detailing
  • hand over to customer’s project lead
  • signed by customer’s project lead and published in ECM

Each state should be traced with

  • actual start (planed start only at drafting)
  • planed and actual end (except for the last one)


advise for reporting tool

Now we getting a clearer picture of what is necessary for our internal documentation. We need a list containing all documents with the dates mentioned above and measures for possible delays. Filters are helping to understand which documents need attention.

„But didn’t you say we should not do excessive scheduling?“ – Right so. The trick is to schedule only document states as they arise. Every document gets a planned start date. When drafting starts you schedule planned end. When drafting finishes you schedule planed end of approval etc. This way you are gaining flexibility at micro level where you need it.

„When you don’t schedule everything how do you execute control ?“ – By defining how many documents have to be in each state after certain intervals (i.e. 10 documents have to be in ECM after one month; all but 10 documents should be published in ECM and none should have less than approval state one month before project closes). You don’t concentrate on schedule but on targets achieved. Depending on the type of work you will use either a linear or an exponential approaching curve. These guarding rails will keep you on track. The maturity of the final work will be the main focus.

„Such a list is not exactly easy to read. How do you get an overview ?“ – Besides using filters there are several ways to aggregate information. Most tool you might be using (MS Excel, MS Access, FileMaker, Apple Numbers etc.) provide the ability to use formulas. You can use them to calculate a percentage done value (i.e. if field „actual end“ of „draft“ contains a date then percentage done is set to 25%) for each document. An overall average might be calculated, too. Counting how many cells contain 25% values gives you the controlling information you want to have. Conditional formatting is able to highlight entries which slipped past due dates. Harvey Balls (Wikipedia) are an other great idea to make things easier to read:


internal tracking

change log

Further aggregation depends on your needs. How much detail do you need to show ? How much detail do you want to show ? Do they need a complete list of all documents because your project is way beyond schedules ? Do you want to give trends ? It depends on your situation how your report will look like.


maturity report overview

maturity report details

A little Excel wizardry may do wonders and create a maturity graph like this:

maturity diagram

Are there limits for this approach ?
Of course. There are several assumptions:

  • there have to be a lot of items to track, not just 3 or 4.
  • the tasks behind should be almost routine work and scaleable.
  • the items should be without dependencies (to each other and to external influence).
  • resource planing is done at a very simplified level.


Copyright notice:
All content of this web page is copyright © 2022 by Karsten Krueger, Kaufbeuren – All Rights Reserved. Any reuse in printed or digital form requires prior written approval by the owner. This specifically prohibits the embedding of this content into iframes or similar technical approaches. Please contact the author thru our contact page if you intent to reuse content from this page. Thank you for your understanding.