Rule 4 - Everything is a project
How we execute projects
Every project has Desired Result, Guidelines, Resources, Accountability and Consequences.
The Informed Captain decides.
If it is not in Notion, it is not a project.
Every project should have the following
Every task, every experiment, every to-do and to some extent every product: whatever activity you can think of is to be defined as a “project”. All projects consist of the following aspects: a Desired Result, Guidelines, Resources, Accountability and Consequences. These aspects are primarily based on the 7 Habits of Highly Effective People and added upon by project management theory from various sources, including the books by and about Jeff Bezos, No Rules Rules and more.
The more you include, the ‘better’ described your project is. ‘Bad’ projects usually miss one or more aspect, or they are not properly defined. For instance, the desired result is not clear. Or more commonly: accountability is not defined so there is no way to measure progress or whether or not a project has been performed properly. If everyone is aligned on these principles, discussion will tend to focus on setting a hypothesis that can be tested, instead of degrading into a yes-no argument.
-
The desired result is the one thing you aim to achieve. This needs to be written down as compact and precise as possible. Do not focus on the how, the who or the methods. Start with the end in mind, and work you way backwards to where you are now, taking into account these five aspects:
Scope: what do you aim to achieve? What are the exact deliverables and their requirements? What do you need to avoid?
Time: when will the project need to be completed? How much time do you need to spend per week?
Budget: how much does it cost the client to deliver the project? How much does it cost us?
Risks: what happens when things go wrong? Perform a post-mortem if needed. Use Nassim Nicholas Taleb risk theory on fat tails as a basis.
Stakeholders: who is your client? who or what is your enemy? What do they expect? Perform a stakeholder mapping if needed.
Note - From the "scope, budget, and time" triangle, keep two of them variable and fix the third one. If the customer is looking for a specific scope, use a variable timeline and budget to finish it. Keep the scope and time flexible if the budget is non-negotiable. And if the project needs to be delivered by a specific date, the scope and budget are on the table.
-
The guidelines are the parameters within which individual operates/restrictions. They are the framework within which the project needs to operate and help you identify the quicksand and where the wild animals are. Perhaps more importantly however, it should also give you guidance on what NOT to do. The following should be covered:
Who - who is part of the team? What are their responsibilities? Make a stakeholder mapping and list each person’s responsibilities. You can use a RACI chart or other ways of mapping which overlaps with accountability.
When - when will you need to complete the project and how much time do you or other team members need to spend weekly? Make a planning, preferably a Gantt chart with milestones (who, what, when, how, responsible).
How - how do you plan to do it? How is communication done? What are the agreements and expectations within the group? What systems will you use to communicate, email, phone, other? What are the requirements of the desired result? Make an overview and schedule the (bi) weekly meetings in all stakeholders’ agenda. Also schedule kick-off, mid-term and evaluation meeting.
-
Which resources are needed to complete the project? At the very least, time or effort from your side is required, most commonly however it includes one or more of the following resources:
Budget: state the price for the client.
People: state the people who need to contribute to the project and how much time is spend.
Knowledge: state the (organizational) knowledge databases from inside or outside your organization, books, websites or other forms of information you can tap into or is missing to fulfil the project.
Tools: state key tools you will be using to complete the projects, such as Excel, Grid, Python, etc.
Other: state any other required resource to complete the project to a successful conclusion.
-
Accountability is about decision-making. Who makes the decisions, how are standards of performance evaluated and under which circumstances is the target reached? If properly defined, there should be no questions, differences in expectations or any unclarities about who decides what.
Define the organizational structure, decision structure, roles and responsibility and mainly: who decides what? Who has budget, planning or other responsibilities?
When is the project considered finalized? How do you ensure a quality project?
Which metrics do you use to measure the project and its quality?
-
Consequences states what will happen - good and bad - as a result of the evaluation. It should be clear for everyone contributing to it from the start. As a team member, you want to know ‘what happens when…? Have I been a good boy and will I get rewarded…?’ Hence, you need to define the following:
What happens when the project outcome is considered good? Will there be extra rewards?
What happens when the project outcome is considered bad? Will there be punishment?
How is the result measured? Who then decides what constitutes a good and bad result?
How to project in 5 steps
The above theory is nice, but what exactly do you need to do? At some point in time, at least 1 admiral decides that ‘a project is born’. Usually this is after verbal agreement of a client (not payment). What then? Who does what exactly? Below the minimum 5 steps that need to be taken to execute a project.
Just as with the Pirate Code, this needs to be considered a guideline. Life and the work we do are in a constant state of change. Therefore it is up to the decision-making authority of the project - Project Manager or PM in most organizations but Informed Captain in Sustainable Ships - to decide to deviate from the below stated points.
-
Go to Projects in Notion, under Operations. There you see a list of projects. Click on ‘New’ to add a project. The three most important people for SS are Informed Captain, First Mate and Additional Crew .
-
Make a cooperation agreement that includes the most important aspects covered by Rule 4. Check the preferred partnership cooperation agreement for an example of what you need to do.
-
One of the most important things to schedule upfront are the meetings. People f*ing love meetings. Send an invite to the client and all crewmates involved so they know when to do deliver what.
-
Make an invoice in Jortt or send a payment link via Squarespace store. It is up to the agreements made with the client which is preferred. For Sustainable Ships, direct linking to the accounting system is preferred, or the least amount of administration or work for the entire process. Informed Captain may deviate but all payments need to be included in Jortt for accounting.
-
Before the kick-off meeting, you need to prepare as much in advance as possible. This usually means customizing a (Decarbonizer) tool. Use Notion, then Squarespace, then Drive. Copy paste from products and projects.
Projects vs. Products
A project is an instance of a product. An instance means a one-time version of something. Additionally, a project usually consumes time to fulfil, while a product does not take time but can be readily used by the client. In other words, we can make a project for Shipowner Paul based on a shore power product. The more we do projects, the more we ‘productize’ our tools, until we have made them fully productized and do not need to spend time on them anymore.
At this point in time, we have projects and a few tools that can almost be considered a product (Decarbonizer and shore power tool). The Nano products are all readily available products which can be bought instantly, without any of our interference. The more projects we will do, the better (and especially faster!) we will make these products.
A project can be external (for a client) or internal (roadmap or other). External projects are paid projects. Internal projects are unpaid. Products are always made for external clients. Multiple projects can slowly transform into a product.
Products are operational, “capaciteitsbehoudend”, focus on repetativeness, operations, process. Projects are singular, “capaciteitsverhogend” of “capaciteitsverbredend”, have risk, require creativity.