Infos

Welcome to THE PROJECT STATUS. The purpose of this app is to support proper project status reporting. Research suggests that transparency and discipline that is achieved by help of status reporting will significantly contribute to project success.

Running projects is difficult and the failure rate is high. Failure means that the project ends with a lower scope or quality, higher expenses, or a longer time frame than planned. If these parameters would have been known at the beginning many of such projects would not have been started in the first place. In addition and on top of all these bad news and even though all the best efforts exercised by the team in most cases the customers end up quite dissatisfied — and the same holds true for the project team.

To reduce the risk of such situations, status reporting for projects is absolutely essential. If the project has a higher complexity than just a very low one, you need to structurally collect and analyse data. Otherwise you are losing the overview and manageability of the project.

Structural information in a project status report

Without the structural information from a project status report you are like a pilot who is flying an aeroplane that does not have instruments. You are basically flying blind. No pilot would ever enter such an aeroplane, but yet still enough project managers would embark on the journey of a project without having regular status reports.

THE PROJECT STATUS app has been designed to support proper and rigorous project control.

Even worse than no status report is a bad status report. To stay in the picture of the pilot, only worse than no instruments are instruments that are misleading. They actually trigger the wrong actions. Unfortunately, there are many project reporting templates in practice, that do not even fulfil the basic requirements of project status reporting: a unique responsible for each deliverable, a unique recipient who assesses the quality of the deliverable and a defined traffic lights scheme that displays the status with regards to delivery dates, budget and time constraints.

Instead, there are project reports that show an overall green status, even though the project is only halfway through and the budget is already 90% used up. There are many more of such deficiencies that can take place in status reporting.

In order to avoid such basic deficiencies and to make THE PROJECT STATUS as useful as possible we the app was based on the 10 Commandments of Project Control.

But, please, evaluate the usefulness of the report for yourself — and let me know what you think. You can reach me at: prof.anders@online.de.

Before you start using the app I also recommend that you quickly read further through the remaining infos so that you are aware of the concept and usage of this app.

Current Version, Agile Development and Best Screen Size

THE PROJECT STATUS app is currently in TEST VERSION 0.17.6.alpha. Alpha means that the app is still under testing and development. The app has already been properly tested, but some errors or some unexpected behavior may remain. The app is online in this early stage to gain experience and to understand critical user behavior or assumptions. Feel invited to already use the app but exercise special care with your data by downloading them regularly.

The app has been developed in a completely agile manner. The plan is to continue the development of this app based on further research and on your feedback. In case you are missing a critical feature or would like to suggest an improvement, please send a message to: prof.anders@online.de.

The app is not optimized for smaller screen sizes yet and it will most probable never be useful on a smartphone. So, I recommend that you use a screen size of at least 1280px in width but wider is better. Below that screen size you may experience distortions.

Disclaimer

You cannot hold the provider of this app liable in case any of the calculations are wrong, mismatching or based on false assumption. Be aware, that any planning is always a simplification of reality and any planning tool needs to make assumptions in order to reduce complexity. You are using THE PROJECT STATUS app at your own discretion and risk and you need to perform your own quality assurance on whatever planning you are performing. If you are in doubt about its correctness or security, don’t use THE PROJECT STATUS.

Design Concept

The structure of THE PROJECT STATUS app is based on the following design concept:

• Everything important should be on the same page, which is the Status Sheet page.
• This central page should combine the executive and the operational perspectives. This means that the executive summary is a direct result of the vertical aggregation of the underlying operational information.
• All numbers and calculations should be easy to comprehend, logical and re-calculable.
• Each status report is based on a defined status date. One can travel through all previous status dates to review the project evolution.
• The look and feel should not differ between agile (KANBAN, SCRUM) or traditional project methodologies.
• There is a progress tab with a chart based project report to get a quick overview where the project stands and what status has been achieved so far.
• As project business is people business the Status Sheet is complemented by a third page, that displays all details of the persons involved in the project.

Printing and Distribution

A project status report is only useful if it is consumed, read and analysed by the people involved in a project and if it then triggers the necessary activities to make the project successful.

For that reason the distribution of the status report is vital.

The recommended way of doing this is to generate a PDF from the Status Sheet page on the current status date. This also has the advantage that the project controller of the project owns the single source of truth and is in full control of the data and the delivery of the report.

The distribution of the report takes place as a push process, e.g. by email or a messenger. Experience has shown, that a push process works in this case better than a pull process where the receiver has to make the effort to first log in into an app before (s)he can get the report.

There are a number of tools that allow for the generation of PDFs from a webpage. Fireshot has received very good reviews but THE PROJECT STATUS does not have any further connection to this app or its company. So, please, judge for yourself and select a solution that suits you best.

Local Data, Data Security, and Working with Several Projects

THE PROJECT STATUS keeps all your data local. So there is no connection to a central app or database. The advantage of this approach is two-fold:

• You do not need to sign in or log in into a central server solution.
• All your project data are on your own hard drive under your own responsibility.

When you work with a project within THE PROJECT STATUS app your data are stored in the local storage of your browser. This means, as long as you are using the same browser, you can continue to work with your data. This feature is called persistency. Should you clean or reset your browser your data will be lost. For that reason it is recommended that you download your data for safety reasons after each working session in which you have made changes.

Your browser can only store and work with one project at a time. If you want to work with several projects at the same time, you need to download the data after your work with the project has finished and upload the data before your work with another project starts.

Download, Upload and Sensitive Data

You can save all your project data by downloading it. You should do this regularly to prevent any data losses. The download file name has your project name and adds a timestamp so you know when you downloaded your data.

The download function also helps you in case you want to collaborate with another person on generating or managing a project plan because you can pass on this download file for upload.

The download file is not encrypted so you can read it by help of an editor of your choice. If you modify the data in the file, you are corrupting it and it cannot be uploaded any longer. But in any case, you should only upload files from trusted sources.

The download file will contain all your project data. Some of these data, including the personal data, may be sensitive. As all data are local, it is your own responsibility to ensure proper encryption and storing of these data, especially if you pass these data on to another person.

Reset, Factory Reset and Crashes

If you want to setup a new project you can click the ‘Reset Project’ button either on the Setup page or the Status Sheet page. The ‘Reset Project’ button deletes all your project setup, deliverables and persons.

Alternatively you can click the ‘Reset Sheet’ button on the Status Sheet page. The ‘Reset Sheet’ button deletes only the sheet including your deliverables but keeps persons and the general project setup.

In case you want to completely reset THE PROJECT STATUS you can also use the Factory Reset. You will find the Factory Reset button down on the left in the page footer. In the very unlikely event that the app should crash and in case you cannot get it back by refreshing your browser a factory reset should also remedy this situation. You can also reach the Factory Reset through this link:

https://app.project-status.org/factory-reset

In case you can reconstruct the error that led to the crash, please let me know the source of the problem, so that I can fix it. You can reach me at: prof.anders@online.de.

Colors

THE PROJECT APP uses the Material color scheme as defined by Google and as summarized by materialui.

A core element of THE PROJECT STATUS app is the traffic light with the extended colors of red, orange, amber, and green. In order to reserve the traffic light colors for the traffic Lights THE PROJECT STATUS uses non traffic light colors for all other purposes, especially: blue, purple, pink, brown, and blue-grey.

Persons

People are the most critical resource for every project. For that reason, THE PROJECT STATUS offers a separate page for them. Often, when you have complex projects a lot of people with different backgrounds or skills, or from different companies meet. Therefore, it is important to keep the overview of the who is who.

For each person you can add the most relevant data. If you enter the roles of a person here, it will also automatically show up one the Setup page and vice versa.

If you are entering personal information make sure that you seek consent from each person and that you adhere to any data protection law. For easier recognition of project members you can also add an Avatar-URL.

New persons can also be entered through the person related forms on the Setup or on the Status Sheet page. All persons entered at these places will automatically be added to the persons list.

Finally, on the Persons page you can also decide if you generally prefer first names or last names for your project.

Status Dates and Status Travel

The Current Status Date is a crucial concept for THE PROJECT STATUS app. At every Status Date the project status should be evaluated. Ideally, the status report will then be sent out to all involved persons in the project at the end of the Current Status Date (or if not all information could be collected because of the complexity of the project a day or two later).

If you have the freedom to pick, a good weekday for a status report is a Wednesday or Thursday, so that people can review the status on a Friday and start taking actions on the upcoming Monday.

THE PROJECT STATUS app supports the work of a project controller by automatically setting the DL — Deadline traffic lights. All DELIVERABLES that have a BY WHEN date that end before the Current Status Day are automatically evaluated. For all other deadlines that are on or after the Current Status Date, the project controller should collect the information on the % - Degree of Completion, the FC — Forecast if the deadline will be reached in time, and the Quality assurance of every DELIVERABLE that has already been delivered.

Once the report for the Current Status Date is completed you want to make the Planned Next Status Date the new Current Status Date. You can do this in the Setup page (please see the description over there for more details).

The Current and all previous Status Dates show in the light blue header line. You can click on every date and thus travel through the past statuses of your project to see the evolution of your project or for review purposes. Information from all past Status Dates are locked and cannot be changed. You can only change the information that belongs to the Current Status Date.

On the right hand side is a symbol for a dustbin. When you click on it, you will delete the Latest Status Date. You can then build a New Status Date based on the information of the Previous Status Date.

Project Setup

THE PROJECT STATUS supports classical (waterfall) projects as well as agile (KANBAN or SCRUM) projects. All general project information can be entered on the project Setup page. Your changes are taken over whenever you are leaving an input field or when you press Enter.

The Setup page has four sections:

• General Information describing the project and the role of persons involved. If you have previously setup the persons involved in the project in the Persons page you can now select them via the menu. If you add persons there the first time, they will automatically show in the Persons page, where you can later add more details if you want.

  Classical and agile projects usually make use of different roles. THE PROJECT STATUS supports both methodologies. If you are not filling in a role, this field will later not show in the executive summary.

• External Ratios are ratios that are not computed from within THE PROJECT STATUS. These are Expenses or Satisfaction figures which need to be supplemented from outside.

• Date and Day Information are essential to manage Dates. At first, you can select the Start Date of your project. Later you can manage your Status Dates in this section. It shows you your Current Status Date. You can also plan for the Next Status Date to announce the Planned Status Date to the persons involved. If you want to turn a Planned Next Status Date into a Confirmed Next Status Date you need to first set the Current Status to ‘Is Completed’ before you can enter a Confirmed Next Status Date. Be careful, once you set the Current Status Date to ‘Is Completed’ all of its values will be locked.

• The Parameters allow you change the coloring of the traffic lights in the ratios section. The numbers are the borders when the traffic light colors would change. For instance 0, 50, 70, 90 would mean: change from red to orange at 50%, change from orange to amber at 70% and change from amber to green at 90%. In this sections you can also change the currency symbol.

Status Sheet

The Status Sheet holds the central information of the project status.

It is comprised of three layers:

• the executive layer,
• the visualization layer,
• the operational layer.

The executive summery layer is comprised of four parts:

• the Project Title with the Objective & Description,
• the Customer(s), Persons & Team, i.e. the involved persons in their assigned roles
• the most relevant Dates, and
• the important Ratios of the project.

All information can be folded in or out.

In the operational layer you can enter your day-to-day project activities and here the information is aggregated up from individual task to the whole of the project. The whole project is then finally summarized in the executive summary layer.

In between the executive and the operational layer is the visualization layer in form of the Gantt-Chart, which can also fold in or out. The Gantt chart represents the individual deliverables that are specified in the rows of the project sheet.

With its visualization, the Gantt-Chart can support both layers the executive one as well as the operational one. This is why it has been chosen to sit in between those two perspectives.

Under the Gantt-Chart follows the actual project sheet that holds the individual deliverables, responsibles, and dependencies of the project — one per row.

Rows, Deliverables and Milestones

Rows in the status sheet reflect project deliverables. There are three types of rows:

• Individual rows, that are not aggregated. Each individual row reflects a project deliverable.
• Aggregated rows, that aggregate underlying rows, which again can be aggregated rows or individual rows. Aggregated rows reflect either a set of deliverables or a list of deliverables.
• The root row, named PROJECT, which is the first row and which aggregates everything.

Aggregated rows have a little triangular at the beginning which is called a caret . In order to keep the overview any aggregated row can be folded or unfolded by clicking on the caret icon.

An aggregated row is a parent to zero or more children rows, that means aggregated rows can also have no sub-rows. In this case the Caret shows in grey instead of the position color.

As a general rule, the color scheme goes from more dominant to less dominant colors the lower an item gets in the hierarchy, i.e. the longer its position becomes.

You can enter WHO, DELIVERS WHAT, BY WHEN, TO WHOM, SPENT, % Degree of Completion, FC — Forecast, Q — Quality, a COMMENT and PRECS into each individual rows. WHO represents the OWNER of a DELIVERABLE. The DELIVERABLE can be an individual item or — on an aggregated level — be a set of DELIVERABLES. PRECS is short for PRECEDENTS and represent deliverables that need to be completed before work can start on the current deliverable.

Each BY WHEN is pinnable. Pinning a BY WHEN is the improved version of a milestone. If you pin a BY WHEN, then the BY WHEN date cannot move any longer to the back. If you pin an aggregated row, no children can move beyond the pinned date.

THE PROJECT STATUS aggregates your information into the aggregating rows above and fills BY WHEN, SPENT, % Degree of Completion, DL — Deadline, FC — Forecast, Q — Quality automatically. For that reason you can only enter WHO, DELIVERS WHAT, TO WHOM, and a COMMENT in aggregated rows.

Each row shows a POSITION. Positions are automatically calculated and show the hierarchical level of your DELIVERABLE.

If you click a row the row highlights in light pink. If you then click on a position, the row will underneath turn into a light blue. This can help you managing the overview or, alternatively, in Kanban depict a fast track for urgent issues.

Sometimes certain DELIVERABLES cannot be resolved from within the project team. In these circumstances you can press the round button under the . The button turns red and the row will be greyed out. The red color reflects an Unresolved Issue. No value from an unresolved issue will be aggregated up.

If you want to ignore a row you can click the round button again. The button will turn from red to black. The row will continue to be greyed out. In this case only the SPENT value will be aggregated. All other values will be ignored. The reasoning for this behavior is that you generally want to keep all issues in the sheet and not delete any in order to have a complete project history. In case a DELIVERABLE was not delivered in a satisfactory manner in the first delivery but then in the second, you do not want to aggregate up the red traffic light from the first issue. But still you need to recognize the effort SPENT for achieving the first delivery.

Note, if you shift click you circle through the states backwards.

Each row is represented by a Gantt-Bar in the Gantt-Chart. Read more about it in the Gantt-Chart section.

Agile and Traditional (KANBAN & SCRUM)

Traditional project methodologies reduce the complexity by making a project breakdown structure. Then individual deliverables are planned in each element of the breakdown structure. So the information hierarchy the traditional methodology is: project → breakdown structure element → deliverables.

Agile methods usually use KANBAN boards. KANBAN boards can be used for the KANBAN project methodology or for SCRUM. KANBAN boards are comprised of lists and cards. Cards contain the deliverables. Lists reflect a status of the deliverable. Thus the status of a card (with a deliverable) is reflected by the list it is on. The card travels to a different list if its status changes, e.g. from NYS to WIP to DONE. As a result the information hierarchy in an agile project is: project → list representing a status → deliverables.

Even though the logic is different, structurally both approaches, agile and traditional, break down the project into parts which then contain the individual deliverables.

THE PROJECT STATUS combines this realization and invents VERTICAL KANBAN. The representation of a project in rows can then be used for both purposes.

In order to make both alternative possibilities more transparent, there is a KANBAN switch. When you switch into KANBAN mode, DELIVERABLES (ITEMS or SET) turn into LISTS & CARDS (FOR DELIVERABLES). Such lists are typically named Product Backlog, Sprint Backlog, Specify, Implement, Validate. Typically you then distinguish two sub-lists under each list: WIP — Work in Progress and DONE

In traditional project methodologies deliverables typically do not change positions. In KANBAN, however, the status of a deliverable is also visualized by moving the deliverable into a different list. In order to not lose the card when it is travelling, the KANBAN mode also shows a short identifier.

In traditional project management deliverables usually also show the precedents, that need to be completed before the work on a deliverable can start. In agile, the work on certain deliverables can become blocked by other deliverables. For that reason, KANBAN mode turns PRECS into BLOCKS.

WIP and WIP Limits, NYS — Not yet started

If work has started on a deliverable with SPENT > 1 and DEGREE < 100% a hourglass appears. This is WIP — Work In Progress.

If not ignored or unresolved, each deliverable has one of three statuses: NYS — Not Yet Started, WIP — Work In Progress, DONE — 100% completed.

Entering Persons

When you click on the fields WHO or TO WHOM, you can type in the responsible person or select it from the pull down menu. If the person is not found, it will automatically be added. Should you want to correct a misprint or should you want to add further details you will immediately find this person in the Persons page.

According to the Essence of Project Management you should always have one unique person responsible for each DELIVERABLE and one for receiving and quality assess the DELIVERABLE. For that reason you can only enter one person in such fields.

Be default the rows are sorted by positions. As an alternative you can sort the columns alphabetically by the names of the owners in the WHO or TO WHOM columns. For that you can click on the icon. The icon then changes into and the rows are re-ordered. In the alphabetical sorting you cannot move, add or delete a row any longer.

Business Days and Hours

THE PROJECT STATUS uses a business week with 5 working days as its underlying calendar. The business day has 8 hours starting a 9 o’clock and ending at 17 o’clock (= 5 p.m.). In the current version 0.17.6.alpha these time points are still hard-wired, in one of the next versions you will be able to change the start and end of day.

Between two tasks that follow each other on the same day is one hour time difference. This means, if one task ends at 11 o’clock the next task will begin at 12 o’clock. If a tasks ends at the end of a business day a subsequent task will begin at the start of the next business day.

Bank holidays or any other form of holidays are not considered.

Dates

THE PROJECT STATUS uses dates only in the form “yyyy-MM-dd”. However, to allow for a fast and convenient input you can also enter the short forms “MM-dd” or just “dd”. In such cases THE PROJECT STATUS complements the missing date information with the information from the Current Status Date.

In order to keep the sheet concise, dates are generally displayed in the shortest from possible. If a BY WHEN is in the same year and month, only the day will be shown. Years are only shown, if they are not the current year.

You cannot enter dates that fall on a weekend. In this case the date is changed to the Monday after the weekend.

Hours

In most projects it will be sufficient to plan on a daily basis. However, should it be necessary to plan on an hourly basis, this is also supported by THE PROJECT STATUS. There is a second smaller field after the date field under BY WHEN. There you can add any number between 10 and 16 representing the hour of the business day. Because the business day begins at 9 any number smaller than 10 does not make sense. Any number greater than 16 is considered to be the end of the business day and is internally assigned to 17 o’clock.

A date that does not show any hours refers to the end of the business day.

Durations

As a basis, durations use a week with 5 business days, a months with 22 business days and a year with 264 business days. When durations are calculated they are shown in the format “1y2m3w4d5” representing 1 year, 2 months, 3 weeks, 4 days and 5 hours. A standalone number in a duration field that does not have a unit (y, m, w, d) always represents hours.

Dependencies: Precedents or Blocks

In the Precedents (or Blocks) input you can enter any precedent that needs to be finished before work on a DELIVERABLE can be started.

The way to input a Precedent is by using the position number of the precedent. Don’t worry, if a position changes the Precedent information will be updated accordingly.

THE PROJECT STATUS app automatically checks for circular references. A circular reference is for instance, if row 01 is a precedent of row 02 and row 02 is a precedent of row 01. In this case you will get a warning message and your input disappears.

It may be helpful to understand that precedents are bequeathed and inherited up and down the hierarchy, excluding the root row. A precedent of a row will also be a precedent to all its descendants and all its ancestors.

THE PROJECT STATUS optimizes your dependencies. If a parent row already has a certain precedent this certain precedent will be deleted from each child of the parent in case it was input as a precedent of this child.

Details

If the switch Details is turned on you can see more details under each row. Should you need more space to enter more precedents (blocks), here is room for it.

Read more about these rest of the details in the »Span, Projection, Slack and From« section.

Adding, Deleting, Moving, and Folding Rows

When you click on a row of a status sheet that is not locked, its background highlights with a light pink. This is the active row.

You can make an active row into an aggregated row by clicking on the caret icon and vice versa. However, rows on level 1 will always be aggregated rows.

You can add or delete rows by clicking on the '+' and '−' symbols. If you want to add a row under an aggregated row you need to click the icon. If a row is deleted all its descendants are also deleted. All precedent information to and all dependent information from this row are then also removed.

You can move an active row. If you move a row all its descendants move with it. By clicking on the arrow symbols rows can be moved up or down and in or out. THE PROJECT STATUS only offers you arrows for movements that are possible.

The movements are pretty predictable. There are only two edge cases:

• Move in: (a) If you are moving in a row that is on a less deep level than its top neighbor of if the top neighbor is an aggregate row, THE PROJECT STATUS understands that you want to move this row under the top next brother of the parent. The app then checks, if this brother is an aggregated row. (b) If you want to move in a row that is filled already and its top neighbor cannot serve as an aggregated row THE PROJECT STATUS recognizes that an aggregation (parent) row is missing and automatically adds one.

• Move out: You can move out individual and aggregated rows. With each click they move one level up. As level 1 only permits aggregated rows, you cannot move out individual rows onto level 1. Only aggregated rows can be moved out to level 1.

• Move up/down: If you move up (down) a row that is already the top (bottom) row in an aggregation, the row will move out of this aggregation row into the neighboring aggregation row to the top (bottom).

Degree Of Completion

One of the most important ratios in project management is the Degree of Completion. On each status date, it should be requested by the project controller from the responsible person for each DELIVERABLE. Together with the specification of the effort already SPENT the Projection can be calculated. The Projection is the expected duration for each DELIVERABLE.

• On individual DELIVERABLES: PROJECTION = SPENT / DEGREE OF COMPLETION.
• On aggregated DELIVERABLES: DEGREE OF COMPLETION = Σ SPENTs|DOC>0 / Σ PROJECTIONs.

In other words: The Degree Of Completion is what has been spent divided by what is projected. In order to not count ‘resultless’ amounts of time, SPENT is only aggregated up if the Degree Of Completion % > 0. Amounts of time that have been spent on tasks that have the status Ignored are not considered in the calculation of the degree of completion.

Traffic lights

Traffic lights form the center of any status report on a project. THE PROJECT STATUS offers three different traffic lights:

• DL — Deadline: This traffic light is automatically set. If on the Current Status Date a DELIVERABLE has a BY WHEN date that is passed and the Degree of Completion is below 100% then the promised deadline has been missed. The traffic light automatically turns red. Otherwise the traffic light turns green.

• FC — Forecast: A status report serves the purpose to also give early warnings. If a deadline is still in the future but it is foreseeable already now that it will be missed this forecast information can already be given. Green indicates, that the deadline will be met, amber indicates some uncertainty, and red an impossibility to meet the deadline. Some projects prefer to use orange instead of red for forecasts. The colorless traffic light symbol only appears for those tasks where the deadline lies after the Current Status Date.

• Q — Quality: Each DELIVERABLE should be quality assured by the recipient once it was received. Green depicts acceptable quality, amber quality under review and red unsatisfactory quality. The traffic light symbol only appears when the degree of completion has been set to 100%.

The traffic light for the Deadline DL is set automatically. The statuses for the Forecast FC or the Quality Q have to be set manually. Click on the traffic light symbols to go forward through the traffic light circle. Shift click lets you go backwards.

In the case a deadline was missed or a quality was unsatisfactory a new DELIVERABLE must be added with a new DEADLINE that remedies the previous shortcomings.

In all cases a COMMENT should be given for all traffic light colors that are not green.

Span, Projection, Slack and From

When you switch on the Details you will find the following information.

In addition to the From, there are three duration numbers that are closely linked to each other: Span, Projection, and Slack.

• From: When does the work on a deliverable start.
• Span: What is the duration between the from date and the by when date. Even though undesired, a Span of 0 can happen and is possible. In this case the Position and the Span are displayed in dark pink.
• Proj: Proj means projection and linearly extrapolates the time already spent on the deliverable.
• Slack: Slack equals Span − Proj. Slack can be considered as some kind of buffer, since the available span duration is larger the projected duration for the deliverable completion. Obviously, negative Slack is possible, which means that the Projection to complete the task is longer than the Span available. If Slack is negative the Position and the Slack are displayed in dark pink.

For aggregated rows the formula Span = Projection + Slack is not longer true. The Span is still the time difference between the beginning and the end of the task. However, Slack is not additive. Thus, it does not make sense to add it up and, therefore, Slack will not be shown on an aggregated levels. Projection in aggregated rows is a compromise: In order to see how much effort in form of total projection needs to take place between these two time points the child projections are added up for each aggregation row.

THE PROJECT STATUS adheres to the Golden Rule of Projekt Management and only focuses on output. For that reason it is only interested in DELIVERABLES and their BY WHEN delivery dates. As a result it always assumes that work on a DELIVERABLE is starting at its earliest possible date. The earliest possible date is called FROM WHEN date. If a task has a given BY WHEN date but for some reason cannot be started at its earliest possible FROM WHEN date the whole task will simply have slack. When the Details switch is turned on, you can see the FROM WHEN date behind the From. But for above reasons you cannot change it. If you want to manage dependencies, have another look at the section Dependencies: Precedents and Dependents.

Aggregation and Inheritance

One of the key features of THE PROJECT STATUS is its automatic aggregation and inheritance.

Aggregation is when information is aggregated from the children rows up into the parents rows. Inheritance is when information is passed down from the parents into the children rows, i.e. the children inherit this information.

Aggregation is automatically carried out for the following fields: BY WHEN, SPENT, % — Degree of Completion, DL — Deadline, FC — Forecast, Q — Quality. In addition, aggregation is also carried out for Span and Projection.

• Traffic lights accumulate by passing up the worst traffic light color.
• Durations are added up.
• Aggregated Degree of Completion is calculated based on the underlying information of Degree of Completion and SPENT per DELIVERABLE.
• If not pinned FROM WHEN dates and BY WHEN Dates result for each aggregated DELIVERABLE from its underlying children.

Inheritance is performed when BY WHEN dates are pinned. In this case no children can be later than the pinned BY WHEN date. Also children inherit the Precedents and Dependents from their parents.

Gantt-Chart and Milestones

The Gantt-Chart is a graphical representation of the DELIVERABLES of a project. A Gantt-Chart is comprised of Gantt-Bars and each Gantt-Bar is comprised of Gantt-Boxes. The initials of the owner (WHO) of the deliverable is shown before the Gantt-Bar, the deliverable thereafter.

For greater clarity you can increase or decrease the size of the Gantt-Chart by clicking on the ’+’ and ’−’ buttons at the top right of the Gantt-Chart. To the left of the ’+’ and ’−’ buttons you see a character ‘d’ (= day) or ‘w’ (= week). With these you can toggle between the day view and the week view of the Gantt Chart.

Since nobody ever knows week numbers, the time line in the week view shows the first date of the business week. Obviously weekends are removed.

Status dates or weeks in which status date occur are shown in blue. The Current Status Date or Week is show in dark pink.

In the day view, each full Gantt-Box represents a full day. In the week view, each full Gantt-Box represents a full week.

A black line at the end of a Gantt-Bar indicates a milestone. The Milestone can be set by pinning a BY WHEN date of a DELIVERABLE. In the day view the milestone is always at the end of the business day even though your task may end during the day.

By clicking on the caret icon left to the Position you can fold and unfold aggregated deliverables. If you click on the Position it will become highlighted.

In the Gantt chart if a bar represents a DELIVERABLE with work that has slack, it will show two colors: the Slack duration has a slightly lighter color then the color for the Projection duration.

Senior Management Requests, Issues and Ratios

Usually, larger projects are embedded in an organization. As larger projects have a more significant impact in the organization they typically bring many stakeholders. Also, the project result may lead to significant changes in the organization itself. The outside area of a project is called the Project Context. Most often the project manager cannot manage issues outside the project and for this needs the support of Top Management that is hierarchical above the project and the project manager. In these cases, Top Management has to perform certain activities.

There are a number of pre-defined and typical requests to senior management from which you can choose on the Setup page. Your own issues can also be added. The selected requests will then show on the Summary Sheet.

The Project Manager has the objective that the project is delivered on time, in scope and quality and within budget. He does so by organizing the deliverables and by making sure that there are owners and receivers for these deliverables. But good project management also has keep an eye on the global level. Are general issues arising in and around the project. These can be change issues in the organization, scope and quality issues of overall nature, risk issues from the context, or knowledge issues during and at the end of the project.

For that reason THE PROJECT STATUS also provides a section on issues. On the project Setup page you can evaluate the severity of such issues and set a checkmark if some measures have already been taken. The information give here is also mirrored on the Status Sheet page.

Remember, project success is defined to be a project delivery of the final product:

• in scope and quality
• in budget
• in time
• with a satisfied customers, and ideally
• with a satisfied team, that is proud on its achievement.

In order to achieve these critical success criteria THE PROJECT PLANNER employs ratios, that directly relate to the definition of project success:

• Expenses Budget T€: the total amount of expenses that has been assigned to the project.

• Expenses Actual T€: the amount of expenses that has been expended from the Start Date of the Project to the Current Status Date.

• Expenses Projection T€: the amount of expenses that will like be expended in the project. It is calculated as Expenses Projection = Expenses Actual / Degree of Completion.

• Time Budget d: the amount of time in business days between the End Date and the Start Date of the project plus one day. Plus one day, because the start day also counts.

• Time Actual d: the amount of time in business days between the Current Status Date and the Start Date of the project plus one day. If the Current Status Date is after the project End Date is set to the Time Budget.

• Time Projection d: the amount of time in business days that will like be expended in the project. It is calculated as Time Projection = Time Actual / Degree of Completion.

• DOC: Degree of Completion. This number tells how much the project is already completed overall. It is based on the DOC numbers per DELIVERABLE and accumulated up.

• DOXS: Degree of Expenses Spent. This number tells how much of the Expenses Budget has already been expended. The underlying budget numbers need to be entered in the project Setup page.

• DOTS: Degree of Time Spent. This number tells how much of the available Time Budget has already been used up.

• DOC/DOXS: Degree of Completion / Degree of Expenses Spent. This number shows if the project is already completed more than the Expenses Budget is spent. Ideally, the number should be above 100%. A traffic light color depicts the criticality of this number.

• DOC/DOTS: Degree of Completion / Degree of Time Spent. This number shows if the project is already completed more than the available time is used up. Ideally, the number should be above 100%. A traffic light color depicts the criticality of this number.

• Customer Satisfaction: Whether or not a project is run in a classical or an agile manner, the (external / internal) customer satisfaction is key. In the end, one way or the other the customer is paying for the project. Therefore, the customer needs to be kept in the picture. This ratio is a reminder for that. The actual number needs to be provided from outside the THE PROJECT STATUS and can be entered on the Setup page.

• Team Satisfaction: A high team satisfaction is an excellent (early warning) indicator as to whether the project is going to be a success. For that reason it should be taken seriously. The actual number needs to be provided from outside the THE PROJECT STATUS and can be entered on the Setup page.

Progress

THE PROJECT STATUS offers a tab that helps to visually analyze the progress of a project by help of charts. The charts show important KPIs (key performance indicators) of the project over time at status days.

On each chart, the first date shown is the project start date, the last date shown is the project end date. The first and the last day of a project may not be status dates, so there might not be information available for these dates. On the line graphs status dates are depicted with a circle, so you can easily see if the start or end date of a project are also status dates.

The lines values between status dates are linearly interpolated. For best visualization, the status dates are equally distributed on the x-axis even though they may have different distances to each other in terms of business days. For that reason, the “straight” budget lines may likely show some kinks.

There are six charts:

• Degree of Completion % (Time & Actual): The Time is linearized from the beginning to the end of the project and shown in blue. The actual values are in dark pink. If the dark pink line is over (under) the blue line the project is ahead of (behind) time in terms of completion.

• Expenses T€ (Budget & Actual): The expenses budget is linearized over time and shown in blue. The Actual values are in dark pink. If the dark pink line is over (under) the blue line the project is more expensive (cheaper) then budgeted.

• Non-Aggregated Deliverables Π (DONE, WIP & NYS): DONE deliverables are in dark blue, WIP (Work In Progress) deliverables in medium blue, and NYS (Not Yet Started) in light blue. Aggregated, unresolved or ignored deliverables are not considered and, therefore, not counted.

• Poor Quality Deliverables & Unresolved Issues Π: Left bar — Poor Quality Deliverables in pieces (Π) are deliverables that are 100% completed but that show a quality of red, orange or yellow. Aggregated, unresolved or ignored deliverables are not considered and, therefore, not counted. Right Bar — Unresolved Issues in pieces (Π) are all deliverables marked as unresolved. Their bars are displayed in colors as defined on the Setup page.

• Number Π of persons involved in the project: Persons counted to the core of the project are assigned to at least one deliverable as WHO or TO WHOM. All other persons are considered to belong to the context of the project.

• Satisfaction: Left bar — Customer Satisfaction in percent. Right bar — Team Satisfaction in percent. Both bars are displayed in colors as defined in the Setup. The maximum is 100%.