How to make P3.express visualization for the team

Now I want to focus on the ways in which we visualized P3.express so that the teams feel comfortable using it. As well as on the key takeaways we identified during the work, I hope this article will help you to work out your own ways to effectively implement P3.express.

👉symbols will indicate useful tips which, however, I did not use for a number of reasons.

1. Collect the source data

The first thing to start with is to bring together those working conditions and nuances which the framework will be applied to:

• Market segment;
• Services/products;
• What draws most of the team's attention
• Under what conditions the team works;
• What resources they use in operational work;
• How knowledge sharing and informing of the events are arranged.

1.1. How external work is organized

Express 42 is a center of DevOps competence and for building IT processes. The company helps to carry out digital transformation, speed up delivery processes and eliminate any obstacles on the way to production. The key focus areas in Express 42 include analysis and consulting, as well as implementation of DevOps practices and training. 

First, I implemented P3.express into the DevOps-practice Unit alone, later I teamed up with a reliable partner. So, from here on, “I” will be replaced by “we”.

Based on the features of our services, I wrote out the following main theses:

1. The average project duration is 1.5-3 months and it implies working on the client’s premises (that is, we connect to the client's infrastructure, work according to their approved methodologies - Kanban, Scrum, Agile, etc.).
2. Several projects are being worked on simultaneously, each of them has different resources (Jira, YouTrack, Trello, Notion, Confluence and many others), and consolidating summary data on the project status is time-consuming and extremely inconvenient.
3. A lion's share of the time is spent on customer communication: clarification of starting positions and where things stand, handing on the activity status and expertise, periodic synchronization according to expectations, getting feedback, etc.

1.2. How internal work is organized

The internal work organization can be learned both by working closely with colleagues, and by asking them point-blank. Moreover, it is necessary to talk with everyone: with teams, team leaders and company managers.

One should make a list of their pains, gaps and problems that are currently observed in the work, their wishes and vision, which can be useful.

At the same time, it makes sense to join several projects as an observer and study how the work “as is” is actually going. It makes all the difference because teams and leads may not notice any problems, but take the unique strengths of the process or participating persons for granted.

Later such notes will help to choose words that are clear for the team when describing the framework and can be used as arguments for its implementation.

In my work, I used text notes, and initially the tasks were as follows:

• Reduce the cognitive load on production so that everyone does their job and spends as little time as possible on any mechanical operations
• Get ready for a higher labor force size, i.e. to prevent possible dilution of expertise
• Make project processes more transparent for both teams and management

 👉 BPMN notation is also perfect to visualize “as is” and “to be”.

1.3. Technical input 

Since team meetings might well drag on for several days / weeks, you can simultaneously study the resources that are used in the company. The technical capabilities of these resources will help you to decide how to visualize the framework.

At Express 42 we use the following:
• slack - for internal communications
• notion as a knowledge base
• miro for process charting, roadmapping and brainstorming

I drew the initial version of the scheme of working with projects and provided comments to it in Miro. Working with a visual representation of “to be” helps to make the process free of unnecessary elements through constant wondering “in order to do what?”.

For example, the project team works within the client’s premises, and we set up an internal workspace, in order to do what? – in order to have the main information on the project in one place, at hand (contacts, stack, meeting calendar, meeting notes, etc.) and available to other departments who work with the same client.

Eventually, one should get a chart, using which you can at a glance understand the key stages and steps in the project life cycle.

1.4. Do not forget about yourself

So, we have an idea of how the team sees the process, the nature of work with clients, and the way the central task will be technically implemented. It would seem to be everything you need to get the job done.

But you’re wrong.

You must always remember about yourself. And help the future self work efficiently, sustainably and stay focused.

For this purpose, I made another list - what I can rely on. The implementation of a new framework is closely related to dealing with uncertainty and high levels of stress. My case was even more complex as I had just joined the company, so I knew the working context by the colleagues’ account and the things I observed only within a couple of projects. In addition, the remote format makes its own changes in the process of data clarification and validation.

And later on, these key points, which I initially determined, helped me a lot to continue moving in the right direction and not to stop.

2. Having one’s work organized

We began talking about P3.express right at the interview. The guys from Express 42 had already seen this framework; some artifacts have already been implemented (for example, the project description and a case creation upon completion of work). And during the source data capturing I was convinced that this framework would really look organic in our work.

Therefore, I will skip the point here about telling colleagues about a new framework and convincing them of its necessity.

2.1. Theory and practice

In my opinion, the framework should be implemented into the company’s life on a staged basis, studying it step by step and gradually adapting it to reality. After all, if you first take a course (or study everything on your own) and then try to apply it to your projects, a bunch of things may arise and you might even want to set aside all previous experiences and start “from scratch”. This is also an option, but my practice and observations suggest that new ideas take root easier and more densely if they rest on an already familiar foundation.

During my first working week, I began the course, gradually compared the theory with what was happening in the company, and sometimes consulted with Dima Ilenkov. This enabled me to promptly determine whether we needed a particular P3.express artifact, or whether it would be redundant. And if needed, how best to adapt it.

For example, we do not use a separate “Health Register” document, because the quality of communication feedback enables fast response to trends. At the same time, the "retrospective" artifact was expanded up to a real tool for ensuring high performing teamwork - we conduct retro not only with the Client, but also within the team. And for better post-analytics, we fix the results of all retros for all projects in one table presented as a section in Notion. And since November 2021 we’ve been making active use of the retro light version for holding meetings within the team. 

 So, I’ve chosen Notion, which describes the framework, as the primary resource, since it is clear-cut and easy-to-understand for colleagues. When writing articles, I was using familiar terms. So, for instance, the “Kick-off” in P3.express was then known as “Kick-off internal” and “Kick-off external”, “Focused communication” - Daily, Weekly followed by sending emails with summaries to participants and stakeholders.

It was decided to give the section containing all the information on the framework a simple name - Project Management Process (PM Process). It had a simple vertical orientation, with the steps described one by one.

To make the information accessible, in each block of work, we marked particular actions that are carried out by team members, Documents that are mainly drawn up by the Project Coordinator, and rules of dealing with the Project Management Information System (PMIS).

When I was making the reference section in Notion, I assumed that the project activities would be carried out sequentially: define goals/objectives - sign documents - gain access - hold a kick-off meeting - work - show the result - hand over expertise and close the project. Everything being the way it's supposed to be.

But I overlooked a key aspect – the project involves several roles. Each of them has its own features and duration.

And we’d better stop here. What was my mistake?

We work with the benefit of hindsight. But sometimes it is still worth putting it aside. The thing is that before I worked as a classic project manager, who managed the project from the first contact with the client at least until the final payment was received after the successful project approval.

Whereas, at Express 42, I coordinate projects. At the same time, both the Account Manager, who accepts the first calls from the company, and the Delivery Manager, who gets involved at the pre-project phase, when the terms of the contract are being settled, always stay in touch with the client. And here it is critical to highlight that each role on the project is responsible for its own job. Accordingly, when performing certain steps on P3.express, team members can connect asynchronously and on a limited basis.

Doing so enables everyone to specialize and improve professional standards in their field, and helps to insure the employee against burnout. It also enhances productivity in meeting the goals.

So, I received a simple message from one of our Delivery Managers:

Seems like we already had a comprehensive manual, except that to answer this simple question it was necessary to read it cover to cover. Well, it’s too time-consuming, problematic, and inconvenient.

So I got to work on making the second version of PM Process.

👉 When implementing a framework, think about the user and their comfort during operation. It’s worth developing user stories and CJM in advance.

3. Unification & adaptation

Over the course of 3 months while the first version of PM Process was in active use, I was able to consciously put together all the criteria for the next version.

They can be expressed like this:
1. one screen principle - the less the user needs to scroll, the easier he will get the relevant information
2. color accents - the faster the user finds the necessary information, the more often he will use it
3. personalization - the user should be able to both have a look at the process all the way through, and filter the steps only for themselves
4. templates and checklists - proper visualization should save the user time so that they can perform meaningful actions
5. remember about uniqueness - your visualization should admit a possibility of additional artifacts that are not included in P3.express, but which are necessary for a particular company

Notion features make it possible to create a board (originally it was a classic kanban board) and customize the required views. Well, yes, the elements of the project operation cycle, which form the framework base, are not reflected here at all. And this sometimes leaves new employees asking questions. But for now, we use this visualization, because it is fit for purpose.

We also put the questions that may sometimes arise during the project in a separate field.

For example, in order not to get confused when the employees’ areas of responsibility overlap, we have written separate articles describing these aspects, and their design concurrently serves as a definition of acronyms and abbreviations and introduces a color separation by roles, which is also supported in other Notion sections.

The "Tools" section presents a collection of descriptions of other frameworks which may be useful for some projects.

The “Project Portfolio” provides insight into what's going on in the pre-sale phase and helps us to easily plan our workload in the future.

The "Good Practices" section is a set of features that were invented and implemented in individual projects and still might be useful elsewhere.

The “Retrospective Summary” allows us to see patterns used in different projects and interact with them individually, yet in the format of the process and tool adjustment that is used by most of the teams.

Particular attention was paid to templates and checklists. Now every project with all its local features looks the same and goes through the same key points.

And almost immediately we received the following gratifying results:
1. the internal workspace is now deployed much faster and a walk-through audit is conducted (readiness to start, to deliver a working phase, to deliver a project, to close the project, etc.)
2. the search for relevant information has become much easier when all projects have the same artifacts located in the same place
3. the human factor is minimized (when something is forgotten or the wheel is reinvented)

Such unification allowed us to immediately see deviations from the norm and, thus, respond to them. This is mission-critical because when you’re involved in a project or operational work you may get the deceptive impression that projects are unique. And adjusting them to a single perception enables you to see common points and duplicate patterns. And work with them in a consistent manner afterwards.

4. Implementation

You can find the perfect framework, you can design it intelligently, you can automate the work to the utmost, but all this is absolutely pointless if the teams do not know how to use it or are not aware of it at all.

We released 2 versions of PM Process at Express 42 during the webinar while this article was being prepared, and each time the process of keeping the teams and management informed was systematic.

To summarize, we can single out the following points:
1. Using common forms of communication to inform employees about changes:

• Every 2 weeks in Express 42 we hold meetings for sharing knowledge. Often at this point, our engineers share interesting technical solutions which they come across in their routine. We used this platform twice (for each version of PM Process) to tell everyone about PM Process simultaneously and send the link to the recording to new employees
• Every Thursday, automatically distributed digests about the project are released. When implementing the first version of PM Process, I posted news every week. It was important for me to put into practice the process name, its location in Notion and remind our team as often as possible of its existence, until all projects were moved to PM Process

2. Consistency in documentation:

• t's imperative that the documents are brought in compliance with each other and contain links to relevant sections. Thus, more employees will use the same information field (including those who are hardly related to projects)

3. A human attitude to the framework integration into the company operation:

• Over the last several years so far, Express 42 has been practicing one-to-one, and last year they introduced coffee random. The employees at Express 42 work from different cities and even countries. And this meeting format allows you to keep in touch and take comforting breaks in workflow tasks. Sometimes at such meetings, the guys ask questions about project management, as they may simply never get around to it in their work.
• At the webinar on December 4 in 2021, I told you that since the moment when the second version of PM Process was made, we’ve had our own mascot. It was honestly filched from the universe in The Hitchhiker's Guide to the Galaxy, because historically Express 42 is closely associated with Douglas Adams’s work.
• The fact that now we have our local memes, for example, “I.WE.PM Process” can be considered as a sign that the framework is seamlessly integrated into the company’s life. Here it is worth clarifying that such memes are not connected with the hashtag I/WE, which became widespread all over the world several years ago. For us, it means harmony and unity in well-coordinated teamwork despite its complex or specific nature.

5. Conclusion

The first release of the framework visualization helped to adjust it to the peculiarities of Express 42, but did not achieve the goals. Starting from the second release, we were able to build best practices which new projects are now following. 

I appeal to everyone who implements P3.express in their company and is reading this article. Besides all the tasks, please, think about your teams, those who will use it. The more comfortable they feel when using the proposed visualization, the faster it answers their personal questions, the better it will fit in their work.

Work on projects has definitely become more transparent and easy-to-understand not only to team members in Express 42, but also to external departments. Also the transition to a flexible and unifying framework allows us to see the project deviations and not to confuse them with its unique features. And, thus, respond to this more rapidly, minimizing or completely eliminating the risk of their recurrence in other projects.