Throughout my career, I have worked in several software houses, helped a few more, and know about a dozen others. And each one faces the same problem – how to effectively manage project knowledge within the company. At first glance, it seems simple. We create an Excel sheet or use a simple editor in SharePoint. When a project appears on the horizon, we add it to the tool and update it as progress is made. In the end, we have a comprehensive set of information on how things went. At least that’s the assumption…
And it usually ends at the assumptions. In none of these companies have I heard of a good summary of information related to past, ongoing, or upcoming projects. In each company, information is scattered across dozens of groups and files, each using different tools and storing data in different formats. Worse yet, these groups rarely communicate with each other. This amplifies the sense of confusion and lack of clear information:
- what we have actually done,
- what we can boast about,
- whether something similar has already happened here.
Frankly, this doesn’t surprise me at all. This is because the project domain is one of the most complex domains from a DDD (Domain-Driven Design) perspective that you can encounter in a software house environment.
Projects – Different Dimensions
The project domain can be divided into several dimensions, which are sometimes included in projects and sometimes not. Let’s start with the informational areas:
- Basic Information – for which client, business needs, from when to when.
- Team Composition – who is in the team, from when to when, with what skills.
- Financial – rate, number of hours spent for a given client, costs, and profits.
- Technical – which technologies in the projects, from when to when, what worked.
- Business – which business areas (e-commerce, aviation, finance, recommendation systems).
You can also look at projects from a time perspective:
- Far on the Horizon – initial leads, general knowledge of technology and project shape.
- Offer on the Table – proposal for the client, with an estimated start, technologies, and people in the project.
- Contracted Projects – we know exactly when we start and with which team.
- Ongoing Projects – changes in technology, participants, scope, deadlines (basically changes in everything 😉).
- Historz – closing projects, conclusions and lessons learned, acquired case studies.
Different Roles Around Projects
You can also look based on stakeholders and the information they require to work. Each group is interested in a different range of project information:
- Salesperson – project sales opportunity, client’s financial capabilities, possible technologies (at a high level), business case studies of delivered projects, technical case studies from specific areas, upsell/cross-sell opportunities.
- Delivery Manager – employees’ skills and their time allocation to current/future teams, overall project status to react if something goes wrong, long-term conclusions, ROI.
- Project Manager – project status (from a delivery perspective), managing project employees, number of hours worked, meeting notes, seeking additional people, business areas.
- Team Member – updating skills based on project experience, reporting problems, checking technologies of other projects to find someone for help.
- Technology Guild – used technologies (in detail), modernization plans, introduced innovations, recommendations, conducting Proof of Concept.
Each role around projects needs a different set of information to function effectively. This leads them to shape information in their way, without considering other roles.
For a salesperson, it doesn’t matter if the project uses Angular version 5 or 13, as they can tell a potential client that Angular projects are ongoing in the company. However, the technology guild will be concerned about using older technologies and the plan for upgrading versions.
The Project Manager wants to record all possible problems and actions within the project. For the Delivery Manager, such detail may be problematic. This role prefers to operate on a much higher level of information.
And it certainly doesn’t help that in each company, these roles do something different and mean something different 😀
Quantitative Differences
Differences will also appear on a quantitative level. Not every project from one group’s perspective will be the same project from another’s perspective.
For example, we might have a several-month project that started and ended successfully from the salespeople’s perspective. For the technology guild, there might have been two Proof of Concepts within that project, finally culminating in the third project. Mapping one to the other is not a simple 1-1 relationship.
Similarly, it might be with an employee. From the employee’s perspective, they are simply assigned to a project. But from the PM’s perspective, their time might be split among several smaller projects, each billed separately to the client. In that case, we effectively have different employees, each at 1/4 FTE.
You don’t even need to think about roles here. Suppose the project initially had one development team. During the work, the project was divided into three smaller ones, and another 10 people were added. Suddenly we have miraculous multiplication 😇 (and structural problems).
Differences in Perspective
All the above leads to differences in viewing the same information. Each group will think differently about the project and its aspects. Hence, there will be a lot of ambiguities, mistakes, and misunderstandings.
The Delivery Manager wants to quickly assess the competencies of people involved in projects. So they create a simple table listing various technologies and ask people for self-assessment. However, employees rebel – what does it mean that I’m a 4-star Azure specialist?
Even something as trivial as the project start date can be unclear. Does the project start when the first PoC is created? When we start discovery workshops? After sprint zero? Each role around the project can define this differently.
And Now the Software
An IT system understood as:
- a place to collect project information
- processes for gathering and processing this knowledge
would have to consider all the above dimensions and nuances. And it’s usually impossible to create such a system. Too many participants, too many perspectives, too few obvious solutions. And above all, too little time to handle it all. That’s why we end up with more Excels, Confluences, or ad-hoc written software that becomes outdated within a year.
Please treat this post as an invitation to a conversation – how does it look in your company? 🙂
