Documentation – About the Rosella Model

Rosella Model Documentation

Everything you need to know about the Rosella Model.

Quick Start

For a background and context, scan the front page. If you are interested in “how to” with the online tools see Reference Implementation #1. If you want to dig into the details of the model see Rosella Model Theory.

If you are looking ‘under the hood’ see Technical Documentation.

Reference Implementation #1

The Rosella Model reference implementation is available at https://rosellamodel.online

Invitation to software tool builders Reference Implementation #1 is designed to bring to life an abstract model. What would it take to bring the benefits of the Rosella Model to your software tools?

Choose your community of practice

The language and graphics used in the user interface shifts to match the preferred styles of your preferred community. Choose your community of practice to get started. Select “PMBOK” to follow along with the explanations below.

The following communities of practice are supported:

PMBOK® Guide
PRINCE2®
Chapter 7 of Norton Brotherton and Fried 2008 “Work Breakdown Structures: The Foundation for Project Management Excellence”

New from a blank or sample project

Click “New” to open a blank or sample project. Select “House Project” to follow along with the explanations below.

Save your project

All Rosella Model data is automatically saved within your browser’s local storage. You can continue where you left off by revisiting https://rosellamodel.online at any time. However, if you clear your browser’s site data, your Rosella Model will also be cleared.

To save your Rosella Model to a file on your local device click “Save”.

Open a project from a file

To open a saved Rosella Model from a file on your local device click “Open”.

Navigating a Rosella Model

Reference Implementation #1’s navigation around a Rosella Model is loosely based on the patterns in https://workflowy.com, just less awesome.

Move focus to an element

The focus element is shown with a darker background. Clicking on the bullet points makes this element the focus element. For example, if we click on “1.1 Foundation Development” the view shifts to

The top row shows the parent elements. Click on the arrows to navigate to those elements.

Control sub element visibility

Clicking on the triangle shapes (shown above) controls the visibility of sub elements.

Navigate back up the hierarchy

Above the focus element there is a list of the parent elements of the focus element. Click on the arrows to navigate back up to that element.

Views

Reference Implementation #1 has three views. The names of the views depend on which community you belong to. For the PMBOK(r) community, these views are:

Breaking down the work
Sequencing the work
Monitoring and Control

Choose a view by clicking on the tab:

The graphic that is shown in each view is also dependent on which community you have chosen.

First View - Breaking down the work

The first view allows us to breakdown the work in the project. The name of this tab will vary depending on the community of practice you have chosen.

Here is the first tab’s view of the “House Project”.

Reference Implementation #1 supports the following basic soundness-preserving operations to breakdown work:

Rename an Element
Add a subtree
Delete a leaf element
Move a subtree
Designate an element as a Work Package and its children as Activities

Invitation to software tool builders The five basic operations above are sufficient to build any desired breakdown structure. What set of soundness preserving operations would better fit project or product owner workflows?

Elements and their Titles

Every element in a Rosella Model is considered to have a dual nature. Each element represents both the deliverable item and the delivery work required.

To capture this dual nature, every element has a dual title. Element’s titles have both a noun part and a verb part.

The noun form captures the name of the output, product, result or service represented by the element.
The verb form captures the delivery activity and work required to deliver the output, product, result or service.

In the Work view, the noun form of the title is used. In the Sequencing and Monitoring and Control views, the verb form of the name is used.

The basic form for entering a title is: “noun|verb”.

Here are some example element titles, separated by the vertical line symbol:

“Foundation Development|Develop Foundation”
“Concrete Pour|Pour Concrete”

In each Rosella Model every element has a unique title. In Reference Implementation #1, duplicate names are either be rejected or automatically disambiguated by the addition of random characters.

Renaming Elements

To rename an element, click on its name.

Automatic Verb Creation

Because of the strong soundness guarantees that the Rosella Model is operating under, Reference Implementation #1 implements automatic creation of the verb form of titles.

Reference Implementation #1 recognises 150 commonly occurring noun phrases and will automatically generate the corresponding verb part of the name. Automatic Verb part creation is triggered if a title is entered without a “|” character in it.

Invitation to software tool builders The automatic verb creation is pretty cool. But with machine learning could be a lot smarter ...

Add a subtree

Any element can be broken-down further by adding a subtree of elements under it. Firstly, move the focus to the element under which you wish to add sub- elements. Then click the + underneath.

this opens the add a breakdown structure dialog

and then paste in the breakdown structure items. For example, if you paste the following outline into an empty project, it will recreate the “House Project” sample without dependencies.

//1 House Project
Primary Structure
    Foundation Development
        Layout-Topography
        Excavation
        Concrete Pour
    Exterior Wall Development
    Roof Development
Electrical Infrastructure
Plumbing Infrastructure
Inside Wall Development - Rough Finish

Deleting an Element

Elements may be deleted by clicking the X next to the name.

Elements can be deleted if:

they are child elements (ie without sub elements)
and the item does not participate in a dependency.

Moving a Subtree

Elements (along with their sub elements) may be moved to be under a different parent element. Firstly, move the focus to the element that you wish to move. Then in the right hand pane the available new locations for the item will be shown as radio button options. For example: for this example WBS:

the element B can be moved. Firstly we focus on B.

This shows that the current parent of B is “This Project”. Clicking on the radio button next to “A” (for example) will move B to be under “A”:

Elements can be moved if the element being moved and the destination parent element are independent and not connected through dependencies.

Designate an element as a Work Package and its children as Activities

Unless told otherwise Reference Implementation #1 assumes a leaf element is a planning package and therefore part of the WBS.

To nominate elements as Activities and their parent element as a Work Package, use the following steps. To illustrate we return to the “House Project” sample project. The highlighted elements are, at present considered to be planning packages and are present in the WBS.

If it is decided that these items (for our purposes) should be considered Activities, click the check box next to their common parent element, and these items become Activities and no longer shown in the WBS.

These items are, of course, shown in the Sequencing view:

These elements can be converted back into Planning Packages by removing the Work Package checkmark against “1.1 Foundation Development”.

Second View - Sequencing the Work

The second view allows us to sequence the work in the project. The name of this tab will vary depending on the community of practice you have chosen.

Here is the second tab’s view of the “House Project”.

The sequencing view uses the verb form of the element’s titles. For example, instead of “1.1.3 Concrete Pour” in the WBS, here we have “1.1.3 Pour Concrete”.

The sequencing view shows the full Rosella Model including the dependencies. For example, if we expand the triangle next to “1.1.3 Pour Concrete” we see that it transcludes “1.1.2 Excavate” as well as “1.1.1 Do Layout-Topography”. The trancluded copies are shown in grey.

The diagram shown in the second view changes depending on the community of practice that is chosen. There are three variants. The Schedule Network Diagram for PMBOK(r) Guide is shown above.

Then here is the Scope Dependency Diagram from ch7 of Norton, Brotherton and Fried 2008:

And here is the PRINCE2 Product Flow Diagram

Reference Implementation #1 supports two kinds of operations in the second view:

Add / Remove a dependency.
Add Preceding or Succeeding elements

The following features of the second view are in the backlog:

Add time basis.
Entry and maintenance of three-point estimates on the Leaf 100% Set (ie Activities and Planning Packages).
Monte Carlo simulation of the model.

Add / Remove a Dependency

To add or remove a dependency Firstly, move the focus to the dependent element. Then choose the elements which precede the focus element from the list at the right. Continue with the “House Project” example above, if we make “3 Build Plumbing Infrastructure” the focus, we can see that it depends on “1 Build Primary Structure”.

If for some reason, we decided that plumbing should follow electrical, we could introduce that dependency by checking the box next to “2 Build Electrical Infrastructure”, and note the change in the diagram.

A dependency can be added when the two elements are independent and currently have no shared dependency.

Adding Successor or Predecessor Elements

During planning successor and/or predecessor elements may be added at the same level as the focus element using these three buttons:

Their functions are:

When the new elements are created, they also have their dependency added so that they precede or succeed the focus element.

Third View - Monitoring and Control

The third view allows us to record progress on delivering the project. The name of this tab will vary depending on the community of practice you have chosen.

Here is the third tabs view on the “House Project” after completing “1.1.1 Do Layout Topography”:

Start and Finish Milestones are automatically marked as completed based on the completion status of their Activities and Planning Packages.

Reference Implementation #1 supports just one operation in the third view:

Mark/ Unmark complete/incomplete for elements on the Leaf 100% Set (ie Activities and Planning Packages).

The following features of the third view are in the backlog:

Gantt Chart view of the model
Entry of Actuals
Reporting on Comparison of Actuals and Estimates

Mark / Unmark complete / incomplete

Elements are marked, complete / incomplete using the tree on the right hand side by checking and unchecking the complete check boxes:

Further Help

If you have questions after reading the instructions above, please reach out to David Pratten on LinkedIn and request an invite to the slack group where you can post your questions.

Rosella Model Theory

The Rosella Model is introduced starting with time-tested project management concepts (Scope, Sequence, Activities) and extended to cover the concepts from Agile inspired methods such as vision, time-boxed sprints, backlog, and kanban.

A word for practitioners The theory below concerning the Rosella Model is not intended for you to use in your daily work. The definitions and ideas below are designed to inform a new generation of software tools for project and product delivery. Rosella Model theory is aimed primarily at software tool makers and at communities of practice who document or formalise methods. Practitioners will benefit from the Rosella Model when it is embedded in software tools. The model is abstract and sits at a level lower than any methodology.

Standard Account of Project Management

In the discussion below the Rosella Model is compared with the “standard account of Project Management”. This refers to the common core of the guidance provided by sources such as:

PMBOK(r) Guide 6th Ed.
PRINCE2 2017
Wikipedia entries for terms such as “Work Breakdown Structure”, Activity and the like.

Elements

The common Project Management concepts such as deliverable, component, summary component, product, work package, planning package and activity are all represented in the Rosella Model as elements.

Every element in a Rosella Model is considered to have a dual nature. Each element represents both the deliverable item and the delivery work required to generate it.

Elements and the standard account of Project Management In the standard account of project management the dual deliverable/delivery nature of elements is acknowledged. The definition of the Work Breakdown Structure as a "deliverable oriented hierarchical decomposition of the work to be executed by the project team." captures the dual nature of "deliverable" and "work". However, it has been usual to reserve the verb form for fundamental elements called Activities. And the noun form is reserved for components, products, work packages and planning packages in the Work Breakdown Structure. The Rosella Model simplifies the model by capturing this dual nature uniformly at all scales.

To capture this dual nature, every element has a dual title. Element’s titles have both a noun part and a verb part.

The noun form captures the name of the output, product, result or service represented by the element.
The verb form captures the delivery activity, effort or work required to deliver the output, product, result or service.

The noun form is for use where the output, product, result or service is referred to, for example in the Work Breakdown Structure. The verb form is used where the associated effort or work is in focus for example, in the project schedule.

In a Rosella Model every element has a unique human-readable title. When written together the noun and verb parts are separated by the vertical line symbol “|”. Here are some example titles:

“Foundation Development|Develop Foundation”
“Concrete Pour|Pour Concrete”.

Delegation to software tools The Rosella Model assumes that software tools actively assist the Project Manager or Product Owner. The dual titles for elements simplifies the model. Reference Implementation #1 of the Rosella Model automatically generates the verb form names, which can be overridden if the practitioner requires. The historical decision to keep noun names and verb names separate was a helpful shortcut when a human had to manage them unsupported by software. Software tooling today can do the 'leg work' and we can simplify our models.

In a Rosella Model every element also has an immutable universally unique identifier which is used internally to refer to elements and their relationships.

Element identity and the standard account of Project Management The Rosella Model is a mathematically well-defined data structure. Part of the mathematical definition is that every element is uniquely identifiable. The standard account of Project Management is less concerned with being well-defined in a mathematical sense.

Scope and the 100% Rule

The Rosella Model represents project scope via a tree shaped breakdown structure which is identical to the Work Breakdown Structure (WBS) or Product Breakdown Structure (PBS) of the standard account.

The Rosella Model implements the 100% Rule which says that (Haugan, 2002) “The next level decomposition of a WBS element (child level) must represent 100 percent of the work applicable to the next higher (parent) element.”

Why is the section above so short? Isn't the WBS an important topic? Yes, it is important, however the reader is assumed to be familiar with the nature of the WBS or PBS. The Rosella Models treatment of the WBS / PBS is orthodox and not much needs to be said.

Sequence and the Schedule Network 100% Rule

The Rosella Model’s way of capturing sequence through dependencies is equivalent to the standard account of Project Management, and introduces the Schedule Network 100% Rule to support and complement the WBS 100% Rule.

The benefits of this include:

Strong model soundness guarantees
Greater delegation to software is possible
Reduction, or elimination, of arbitrarily created “work completed” milestones.
Harmonisation and alignment of Breakdown Structure and Schedule Network milestones and therefore vocabulary
What was previously was purely a project model can be seamlessly extended to also be a product delivery model.

Schedule Network and the standard account of Project Management In the standard account of Project Management the practitioner is warned about the need to ensure that the Schedule Network is sound. This is because the standard account invites the practitioner to build a Schedule Network by adding dependencies to an unstructured list of activities. In contrast, the Rosella Model delegates creating a coherent Schedule Network from the WBS to software and as dependencies are added, software ensures that the model remains sound.

Schedule Network 100% Rule

The Schedule Network 100% Rule (Pratten, 2016) is introduced below through a series of examples and then formally defined.

The simplest possible WBS

wpg_div_wbs0

has as the following as its equivalent Schedule Network, noting the shift from noun title to verb title.

wpg_div_sn0

This is the base case for translation from the WBS to the Schedule Network. The lowest level in the WBS is represented by itself in the Schedule Network.

The next most simple WBS has 100% of the work required to deliver A broken down into two elements B and C.

wpg_div_wbs2_a

The equivalent Schedule Network is as follows. Note the introduction of a pair of milestones to capture the start and finish of A. The following diagram can be read as for the WBS, to deliver A, we need to deliver B and C. The diagram carries no information about the sequence of B and C.

wpg_div_sn2a

This illustrates the second case that needs to be considered to translate the WBS into an equivalent Schedule Network – each summary component is represented by a pair of Start and Finish milestones.

An arbitrarily complicated WBS can also be transformed into a coherent Schedule Network using the same two cases. Here is another simple example WBS:

wpg_div_wbs2

Here is an animation that shows the transformation from the shape of the WBS to the shape of the Schedule Network.

And its equivalent Schedule Network.

wpg_div_sn2

The preceding examples illustrate the Schedule Network 100% rule which says “A summary activity’s start milestone must precede, and its finish milestone must succeed, 100 percent of the work applicable to the summary activity.”

WBS 100% and the Schedule Network 100% are consistent

The harmony and consistency between the WBS 100% rule and the Schedule Network 100% can be shown by the example below. Let’s say that we have a degenerate WBS:

wpg_div_dwbs

By the WBS 100% rule we can say that A, B and C all refer to the same deliverable and delivery work. Adding B and C has added no information to the WBS.

Let’s apply the Schedule Network 100% rule and derive the equivalent Schedule Network.

wpg_div_dsn

This Schedule Network says that the Start of A, B and C coincide, and that the finish of C, B and A coincide. Therefore, it also says that A, B and C all refer to the same deliverable and delivery work.

The Schedule Network 100% rule leads to a similarly degenerate Schedule Network. B and C can be removed without loss of information.

Why haven't I heard of the Schedule Network 100% rule before? That is a good question. One possibility is that the relative stability of the predictive project environment didn't require any of the benefits unlocked by this rule.

Deep connection between the WBS and the Schedule Network

The Rosella Model captures the deep connection between the WBS and the Schedule Network that we have seen above.

It is surprising; however, it turns out that the WBS and the Schedule Network are isomorphic or dual. In popular idiom they are yin and yang.

The uncovering of this dual nature opens the possibility for further simplification of the project model. The WBS and the Schedule Network are the same deep structure, just presented in different forms for different audiences. One is a tree and one is a directed acyclic graph.

Any Schedule Network which obey’s the Schedule Network 100% rule, can be converted to its equivalent WBS and back without loss.

Sequence

Separate structures or two forms of the same structure? The standard account of Project Management. In the standard account of Project Management the WBS and the Schedule are considered to be separate structures, commonly created using different tools. Success in creating one doesn't tell us anything about the success of the second. In contrast, in the Rosella Model, once one has created a WBS, the Rosella model can be viewed either as a WBS or as the equivalent Schedule Network without further user input. This is because in the Rosella Model there is only one structure that underlies both!

In the Rosella Model elements are put in sequence using dependencies in the same way as in the standard account of Project Management. However, this needs to be done without splitting the WBS and the Schedule into two different structures.

The Rosella Model captures dependencies within a single structure using an operation called transclusion.

To illustrate this, let’s take the simplest interesting WBS:

wpg_div_wbs1

And let’s assume that B generates outputs that are required by C. That is C depends on B. In the Rosella Model, this is captured by a transcluded copy of B being added to C.

wpg_div_rm1

This structure above is not a WBS. It is a Rosella Model.

Formally, it is a tree with transcluded copies of incomparable elements. This data structure is the heart of the Rosella model.

Where else might I find transclusion? Transclusion is used in Confluence (by Atlassian) and in Wikipedia to include the content of one page into another.

Deriving the WBS from the Rosella Model above with a dependency is trivial – just ignore the transcluded items.

wpg_div_wbsabc

Deriving the Schedule Network from the Rosella Model is accomplished in a few steps which are all fully automatable.

Firstly, we create the Schedule Network from the WBS, as above, following the Schedule Network 100% rule.

wpg_div_dep1

Secondly, we add the dependency.

wpg_div_dep2

Thirdly, we observe which of the existing dependencies are no longer required by the Schedule Network 100% rule and are made redundant by the new dependency. These redundant dependencies are shown below grey and dashed. (We are exploiting the transitive closure of the dependency relation here.)

wpg_div_dep3

Finally, we remove the redundant dependencies to show the simplified Schedule Network which is coherent with the WBS and shows the correct sequence.

wpg_div_dep4

The Schedule Network is always sound and in harmony with the WBS.

Activities and Work Packages and 100% Sets

To this point, we have not discussed elements which are commonly called “Activities” and “Work Packages”. Before we can define an element as an “Activity” or a “Work Package” in the Rosella Model we need to explore what these terms refer to, and we will then use 100% Sets to define them.

Activities and Work Packages

In the standard account of Project Management,

an “Activity”
- is “A distinct, scheduled portion of work performed during the course of a project.” (PMBOK Guide 6th Ed.) and therefore, appears in the Schedule Network, and
- is linked to one, and only one, WBS Work Package however, it doesn’t appear in the WBS.
a “Work Package”
- is “The work defined at the lowest level of the work breakdown structure …” (PMBOK Guide 6th Ed.)
a “Planning Package” is a Work Package which has not yet been broken down into activities.

To make this discussion more concrete let’s recall the simplest possible WBS. In this WBS, we have two Planning Packages B and C.

wpg_div_simplestinteresting

Let’s assume that B becomes a Work Package by the creation of three (blue) activities called D,E, and F.

wpg_div_threeactivities

The Rosella Model approaches definitions like “Work Package” and “Activity” from a whole of model perspective and reframes the definition’s above to start with the membership of the WBS and the Schedule Network and from there to derive definitions for “Work Packages” and “Activities”.

Basic elements of the Schedule Network

The Rosella Model assumes that categorisation of elements (e.g. Activity, Work Package) must be guaranteed to be done across 100% of the project scope.

The basic elements in the Schedule Network are those at the lowest level in this tree structure, D, E, F, and C these elements will hold our estimates and actuals.

wpg_div_leaf

These four elements, D, E, F, and C cover 100% of the scope of A. A set like this is technically called an antichain. For the purposes of the Rosella Model we are going to call these “100% Sets”.

A 100% Set is a set of elements that covers 100% of the project scope.

The set of four nodes, D, E, F and C above form what is called the “Leaf 100% Set”. That is, all the elements which are at the lowest level in the Rosella Model.

100% Sets are a building block in the Rosella Model There are many contexts in project and product management where we would like to apply a category to 100% of the scope. Two examples that spring to mind include: 1) Risk ownership being allocated at the right level right across the project with the 'right' level differing between different parts of the project. 2) Control Accounts are allocated once and once only for 100% of the scope with the 'right' level differing between different parts of the project. The Rosella Model will use 100% Sets to model both these and provide strong guarantees to the Project or Product Owner that nothing has been overlooked.

Membership of the WBS

In our example, the lowest level in the WBS is represented in the Rosella Model as another 100% Set called the “WBS 100% Set” consisting of just two elements B and C which cover 100% of the scope.

wpg_div_wbsmember

In the Rosella Model, 100% Sets which are at a higher level than the Leaf 100% Set are defined using marks on elements. You can see that the element B carries a mark. In the case of the WBS 100% Set, an element with a single level of child elements and carrying a mark is a Work Package in the “WBS 100% Set”.

Defining Work Packages, Planning Packages, and Activities

With the Leaf and WBS 100% Sets defined we can now show how Activities and Work Packages are defined in the Rosella Model.

Work Package – A member of the WBS 100% Set that is not in the Leaf 100% Set.

Planning Package – A member of the WBS 100% Set that is also in the Leaf 100% Set.

Activity – A member of the Leaf 100% Set which has as a parent a member of WBS 100% Set.

Work Packages, Planning Packages, and Activities and the standard account of Project Management Rosella Model's definitions of these terms is thoroughly orthodox. Doing it in such a way that we have provably applied the category to 100% of the project scope is novel. The standard account of Project Management provides definitions which focus in a natural way on individual elements of work or delivery. The Rosella Model's approach here is another example of the strong soundness guarantees that it offers and the foundation for delegation of more work to our software tools.

What happens if we decide that D, E, and F are bigger pieces of work that need to be broken down?

If we decide that D, E, and F themselves need to be broken down into smaller units then all we have to do is remove the Work Package mark from B and the WBS 100% Set and the Leaf 100% Set will be the same. Then D, E, and F would be Planning Packages (not Activities) and appear in the WBS. B becomes a Summary Component of the WBS.

wpg_div_wbsmember2

Implementing Agile Inspired Methods

It is believed that the theoretical basis above is sufficiently strong and sound to enable the representation of Agile inspired methods such as time boxed sprints, backlogs and Kanban. This is the subject of “Rosella Change Proposal 3 – Vision for First Class Support of Agile Inspired Methods“.

You are invited to contribute! Rosella Change Proposal 3 (link above) is available for public comment. If you would like to contribute to the effort to build an abstract model that seamlessly accommodates both project and product delivery (with iteration) then your input as comments is welcome.

Once Rosella Change Proposal 3 is implemented, the underlying theory will be documented here…

© 2020 David Pratten
This work is licensed under a Creative Commons Attribution 4.0 International License.
Executable versions of the model are published and licensed using the MIT License

Edit