I failed as PM

I know how challenging the role of Project Manager is. 

I was hired in 2014 as a Project Manager by a small polish startup company. Initially it looked like a challenge and opportunity to learn how to manage projects. However it turned out to be mission impossible. I failed and eventually was fired. 

A few months later the company was closed due to lack of adequate financing so it is hard to judge what went wrong. 

For me it was a priceless experience. I learned there is how much trouble PM can have when he lacks good software requirements. 

How could it happen that I didn’t write them myself? I knew this was a big problem. I also knew how to write them. Well, I was just too busy putting down fires to actually write down specifications. 

I had to handle many conversations:

• talking over the phone with my boss for hours
• talking with developers to motivate them to work 
• expedite some new features or bug fixes to developers

This took time which I could not spend on my main responsibility: meeting the deadlines. I understood my role as Project Manager as somehow managing to deliver projects on time and with acceptable quality. 

Common problems in IT 

I participated in many IT projects for the last 18 years. I experienced a number of bad things that can happen during every IT project:

• lack of specific skills or knowledge in the team

• lack of requirements

• lack of development or test environments

• lack of access to necessary systems

• missing software licenses

• lack of necessary decisions or approvals

• problems with bad architectural decisions

• lack of knowledge management system

• unsolved dependencies from other teams and projects

Enough to make anyone's life miserable. 

An experienced Project Manager could probably add another 20 things to this list starting from office politics. 

You can't allow for these things to persist for long. Something has to be done so the project can progress. However there is too much work and too little time. Nothing is simple.

You see, I know these pains. I experienced them and I saw different PMs frustrated about some of these. 

What I want to do here in this article is to show you how to get some room to breathe. I won’t solve these problems for you but I can show you where you can find so much needed time. 

You need to start saving time

It is all about saving time. 

Skilled worker finishes his work quicker. Requirements engineering best practices will get some time back to you. You will gain these: 

• quicker planning

• quicker clarifications of requirements

• less source code rework

• fewer bugs

• less time needed for software development by simplifying the business process

It all starts with proper communication. You see the problem is that we can not fully communicate requirements just by word of mouth. We have to put things into writing. 

However people are only used to writing emails, notes or articles. These are not good to communicate software functionality. 

To communicate requirements you need something different and I will get to it here.

Paradox: to save time you need to spend more time on requirements communication

I want to focus here on achievable things you can introduce to your projects. 

You or someone else shall write down pieces of specification which I will explain below. 

I picked techniques that I think are applicable to any IT project and which are not very time consuming compared to the benefits they give. Let’s call it best practices. 

By applying them you will get back more time than you invested. Once you get some experience with it you will know how to efficiently handle any project.

You shall introduce these best practices one at a time. You shall stop reading this article after first best practice and leave to implement it in your project. Get back here only after the first best practice is in place and you want to introduce the next one.

I do not know much about Project Management and I won’t write articles about it. You may forget anything I write about Project Management.

However I do know something about communicating requirements. I have been practicing it for about 15 years.  What I write about communicating requirements is a result of very long search and observations in various IT projects. 

Let’s go. 

Best practice #1. Entity Relationship Diagram

You need to make sure that software developers understand the basics about the business domain. 

For example if you work in the banking system everyone shall know what is an account and a transaction. What is even more important and often tricky is how transactions are related to the account. 

It may sound obvious but in an average size project you would have at least 20 various domain objects. Understanding how they are related will save you a lot of time. 

Language matters

Right now I am working on a merger of two Transfer Agents (a type of company that exists on the stock exchange to help investors and companies to handle trading and maintain ownership). ‘Account’ for one company is actually something different from ‘account’ for the second company. 

You see the differences in terms can create a lot of misunderstandings. 

What you need is a single Entity Relationship Diagram for your project. It is the first thing that you shall do in every IT project in terms of requirements communication. 

When you follow Agile software methodology it is even more important. I strongly believe that working on the proper language and domain model can save you some time.

ERD is all about language that is necessary to describe the real world. It is a method to find an elegant data model of the business domain. 

This type of diagram is easy to understand by both software developers and subject matter experts. You have to stick to business language. 

Relationships between elements are easy to memorize thanks to so-called Crow Foot Notation. It is not like BPMN where you have dozens of symbols. Here you have only one type of entity and 4 different relationships which have intuitive symbols. 

The moment you show ERD to software developers some good things will start to happen. Very quickly your software developers start to understand something about the business for which they are supposed to create an IT system. They can already start development by: creating database schema and also backend APIs. 

Another amazing thing is that whoever is designing the user interface will be able to create a better information architecture thanks to the ERD. Check the first case study at the end of this section to see how ERD helps with UI design.

IT projects are all about communication

You need to be very careful when trying to understand requirements for the first time. Most of the time it is uncomfortable to talk about things you do not know. However you need to get over it and ERD diagrams actually will help you a lot. It is quite comfortable to sit with experts and discuss ERD. 

Some things are just so obvious for experts that they will never think to communicate it. But they are not the people who will be writing code. You need to always remember that software developers do not understand the end users. This will almost for sure cost you some rework. 

You will also need to repeat discussions about some requirements. I saw many times that there are some parts of the systems which are being discussed over and over again. This is where you can lose many hours of your precious time.

The tool

Ok so how to do it? I like a free and simple software called yEd.

You need to install it and create your first ERD. It will be made of three types of information: 

• elements

• attributes

• relations

Examples

You can actually see examples of a few Entity Relationship diagrams done in yEd on my web page.

As you will see there is ERD in every example on my page. For me it is a rule of a thumb - every IT project shall start by creating ERD. 

Most legacy IT systems I saw didn’t have ERD created. It means that most people will not see value from doing it. You can convince them by saying this: if we already have a good understanding of the business domain - then it won’t take us long to create the ERD. 

However if it takes time to create ERD - it means that we have a hard time understanding the business domain and we can make serious mistakes.

It is better to learn by drawing ERD than by listening to customer complaints during User Acceptance Tests.

Rationale

Ok, so what is there on ERD that makes it such a wonderful tool?

There are all relationships between various terms which make up the business domain. For example:

• one account can hold one or more securities

• How many different currencies can you hold in your bank account? Usually one, however there are some companies that allow you to create one account where you can hold multiple currencies and quickly trade from one currency to another. e.g. Revolut or Zen

The type of relationship can totally change the scope of your IT project.

I saw many legacy systems which had database schemas that didn’t reflect the real world. Because of that there are problems with code:

• it gets more complex than it should be

• it gets harder to understand and to maintain

• it had additional steps to map and transform fields. On every step you need to perform additional calculations to provide even simple functionality like viewing basic data

The end result after a few years seems to be the same - everyone thinks that applications should be rewritten to the new technology. 

Neglection to do ERDs leads to huge rework. It is also not so easy to rewrite a system.

Podcast

You can listen to my podcast episode about ERDs - it is in Polish: Apple podcasts or Spotify.

Episode 8 explains more about creating a common language between tech and business by applying ERD. In episode 5 I talk about case studies below.

Case studies:

Startup

First case study is from my startup idea. 

Yes, ERD also applies to startups. After all, they are also IT projects. My startup idea concerned presentation of ceramic tiles on a manufacturer website or online shop. 

All ceramic tiles are grouped into collections. This is what everyone can understand without drawing an ERD. 

I discovered thanks to drawing an ERD that there are so called ‘arrangements’. Arrangement is a room finished with specific collections of tiles, e.g. a kitchen or a bathroom. 

While looking for tiles you would actually prefer to start from pictures of arrangements. You can even find paper catalogs where pictures of arrangements take most of the space and they are always at the top. 

I tested websites of many ceramic tile manufacturers. I also tested many online shops.

No one from IT companies that implemented these websites has ever thought of ‘arrangement’ as a part of the domain. As a result the usability of all these applications is questionable and people actually pick ceramic tiles by visiting shops. 

One ERD diagram actually shows that you can look at picking ceramic tiles via webpage in a completely different way. Without ERD you just follow what other people did and there is no innovation.

What we did in our startup was searching through pictures of arrangements. You could pick colors you are interested in and we would display you only matching arrangements. 

It was completely different from anything I saw before. ERD played the key part in understanding the real world. It helped us deliver a very innovative solution.

Billing

Second case study is from a very large telecommunication company. 

Company is a leader in its market. They actually created a service which all of us can benefit from. They made the internet fast. Their services are acquired by companies all over the world who pay large amounts of money for it. 

This innovative corporation has actually big problems with explaining invoices they send. These problems are so meaningful that they decided to invest in an IT program to explain the costs of invoices. Many people across a few departments were engaged in this program. New reporting system was created as well as a new platform for gathering the data. 

Unfortunately all the work they do will not solve the root cause of the problem.

I worked for them and I was in this reporting project. I decided to create an ERD to understand how billing works. 

What I discovered was there is a central entity called ‘billing model’ which connects everything else together. It is the name of an equation used to calculate the cost of specific service. 

Due to the billing model you could have one, two or more separate payments for the same service. To understand the cost of a specific service you need to show invoice items grouped under a billing model. 

However this company didn’t have a billing model anywhere in their systems. 

My team couldn’t do anything about solving this problem. I tried to communicate it to other departments and I am not sure if the message got through to the right people. I believe it would be very hard for many people to admit to such a mistake.

The costs of fixing it are huge because you need to change the data model in big IT systems. On the other hand this has to be done to finally be able to have transparent invoices.

Tax calculations - Cost Basis

Third case study is from the financial institution Cost Basis project. 

Cost Basis is all about calculating the taxes from selling shares on Stock Exchange. Unfortunately for investors they have to pay tax each time they earn some money on the stock exchange.  

When these regulations came up in the US around 2011 the company I worked for, had to quickly create a system for calculating taxes. It was done too quickly and all data was thrown into one basket. For sure no one did ERD for this system. 

When I started working on this system it was 10 years old. It was used in production for literally millions of transactions. There were about 170 million so-called Tax Lots. Tax Lots are created based on buy and sell transactions but usually there are more tax lots than transactions.

I worked for a year on detailed analysis of this data and I wrote hundreds of SQL queries to check it. 

One interesting topic for many discussions was Wash Sales. This is the type of ‘interesting’ thing that you do not want to see in your project if you are a PM. It is interesting for me because there is a lot of business logic behind it. 

However it was a source of performance problems which caused one of our processes to run for a month. Yes, we started a process on our UAT environment at the beginning of September and it lasted until the same date in October. Normally you would say that it is very inefficient code but we had some decent software developers there. 

The Wash Sales and a few other things took so much processing time when we had over 100 million debit tax lots and over 100 million credit tax lots. It was a one time processing that we had to do for historical data but still - one month. 

In terms of quality assurance, having to wait for one month is a nightmare. I never saw anything even close to this.

You see, Wash Sale is the simplest way to not pay taxes. Wash Sale works like this: you own 100 shares of IBM. 

Today the market price per share is 136 USD. You sell it today. When you bought them in November 2022 they cost 141 USD. You lost 5 USD per share so you just lost 500 USD. This is your cost which you can add to your tax statement and do not pay any taxes for another 500 USD which you earned on some other shares. 

Life is great. It is great because you plan to buy back these 100 IBM shares in two days. The price should still be around 136 USD. Easiest way in the world to avoid paying taxes. 

Unfortunately for investors there is a regulation which says that buying back shares within 30 days since they were sold with a loss is a Wash Sale. It will be treated as if you had not sold them. 

Our system was responsible for catching every. It was complex because every Wash Sale involves not just one but at least three different transactions (Buy, Sell, Buy). You need to somehow match these transactions.

You see a Wash Sale shall be a rectangle on your ERD. It shall be linked with a transaction rectangle and the relationship shall be one to many. 

Information about which transactions are linked to specific Wash Sale shall be stored in the database. However in the legacy system I worked with there was no dedicated table in the database for wash sales. 

Instead wash sale information like dates and rates were buried together with another 200 parameters under the tax lot umbrella. Most of the time tax lots had these wash sale parameters empty. It was a mess. 

This mess cost the company time and money. They had two experienced people hired who spent a large part of the year on checking if Wash Sales were properly calculated. It took months of work every year. Just because no one created ERD back in 2011.

Best practise #2. Task Descriptions

To save time you shall document the ideal business process. 

You shall do it not because the success of the whole project depends on satisfied stakeholders. Nor the reason is to take care for end user users to allow them to fully complete their tasks. Neither the reason is to automate as much as possible. 

The reason is that documenting the ideal process will cause following effects:

• it will save your time as a PM

• you will not have to worry anymore about communicating the requirements

• user acceptance tests will be smoother with less rework

• the whole project scope will be much more transparent to you and to stakeholders which will make it easier to prioritize

• most importantly you will show to your developers that their work makes sense: this feeling that the work makes sense is important

Task Descriptions

All of this can be accomplished thanks to so-called Task Descriptions. 

Not very well known because they are techniques born in between requirements engineering and Human Computer Interaction. 

It is a technique that bridges the gap between system analysis and user interface design. It sounds complex but it is pretty simple. 

Interpretation of Task Description is very simple and quick. Writing is more complex but I am here to help you. 

You can see examples of many Task Descriptions on my website.

You can also understand it better by listening to my podcast:

Episode 18: Apple podcasts or Spotify

Episode 6: Apple podcasts or Spotify

Ideal business process saves time for the Project Manager

How many times have you participated in meetings or discussions about the same feature? Is it always only once? 

How many times people discuss the business process without writing it down? Are there some processes that have to be explained over and over again?

If only there would be a perfect way of writing down the business process. 

• concise

• not too detailed 

• not too abstract

• easy to read

• with clear explanation of the value for the end users

• a way where you can be sure that all user needs are satisfied 

It would be so cool to have such a method and write down the scope of your project this way. Such a nice dream.

Your project becomes a list of business processes where you can implement them one by one. You could have 10 or 40 such business processes but you always know it is the complete list and nothing else is in the agreed scope. 

The risk of scope creep stops existing. Stakeholders are not calling you to ask for new features because everything is already written down and communicated.

Is it just a dream?

Such a perfect business process modeling technique exists. 

It actually took me 6 months of studies to find such a method. 

I quit my job in ABB and started studying the topic of usability. I was specifically searching for a connection between requirements and user interface design. Initially I was not finding anything specific. It was often very philosophical. 

Script books were interesting but not very helpful so I started searching articles on the web. I found a few similar articles which all focused on activities performed by end users.  

The best one was written by prof. Soren Lauesen from Copenhagen. He did research for the government where he created so-called Task Descriptions. I got excited about it the moment I read his article.

I applied Task Descriptions in a number of projects and they work as a charm. No one has problems with understanding them. 

I even simplified writing them by skipping the variants which I would rather write as atomic requirements. My way of using Task Description is all about finding the ideal business process.

How does it work?

Basically you have to split the business process from the actual IT solution. Easy to say but without the proper method it is impossible. 

User Stories are already a definition of a specific solution - and only a small part of a bigger business process. 

Use Cases have steps which tell what the user does and what the computer does - it mixes process description with actual solution. 

One would think that Business Process Modeling Notation is what we need. Unfortunately in practice it doesn’t communicate requirements very well. BPMN is hard to read and usually one diagram contains both too many details and is too abstract at the same time. Sounds crazy for a well established method but it is what it is. 

Task Descriptions actually split the business process from the actual solution. 

Task Description has a title - the name of business process - it is a task done by the user which brings some business benefits. Task Description also has a table with two columns which describe the business process one step at a time.

The first column contains substeps of the business process. When you do it you do not care if the step is done by the user or by the computer. You assume that they do it together. 

In a single step there can be both heavy computing, light speed telecommunication and human intelligence. What matters is what actually happens in a specific step to get closer to finishing the business process.

The second column is a place where you write down what a computer can do to help with this specific substep. You can put many ideas here. You can ask software developers if they have some more ideas. 

It shall be very easy to come up with solutions once you see the business process. 

Case studies:

Trading mobile application

I was working with a marketing person on a scope of a new mobile application. 

It was for trading on the stock exchange so there were functionalities for:

• registering your account

• transferring money

• buying and selling shares 

• some reporting functionalities

It took us only 7 working days to write down both Task Descriptions and create ERD. It was so fast because I worked directly with Charlotte who was from marketing. She had just completed market research which was very thorough and took a few months.

We were sitting together with Charlotte writing down Task Descriptions for a few hours every day. After a week she learned how to do it and created a few Task Descriptions herself. They were pretty good and I only edited them slightly.

The end result was that developers were able to estimate the project. I can’t tell you more because there was an acquisition that happened shortly after it and the project was stopped. 

However it was a great example showing how quickly you can create 40 Task Descriptions.

Business workflow application

I was working for some time on a business workflow application. 

My organization handled complex cases like inheritance of held securities. This is what happens when your wealthy aunt dies and you are entitled to get some shares. Processing of ownership is complex and involves many activities like sending back and forth paper forms. 

Every day the office in Minnesota received mail. 

A carriage of letters. 

There was literally a carriage which the mailman used to bring the letters. 

There were hundreds of letters every day. 

Some of the letters could not be delivered and they got back to us. Those we wanted to quickly scan and mark as undelivered in our IT system.

I modeled the process of scanning such letters with a barcode scanner. 

I wrote a Task Description and discussed every step with our subject matter expert. Our UX designer created wireframes exactly following the Task Description. 

I went from not knowing anything about scanning to designing a business process that was super fast. 

User has only to trigger the scanning mode in the UI and then physically scan letter by letter with a barcode reader connected by USB. The software did the rest and informed the user about the progress. It was super simple. 

This is what Task Descriptions are all about - they make you invent the perfect business process.

User permissions management

I was working on a new platform for managing access for multiple customer facing systems. Basically you need a tool where you can control who has access to which features and to which customer data. 

At the same time this is a system where thousands of companies hold their data and you need to be very careful when granting access. 

In the past it happened that instead of giving access to Company A data to Paul Smith from Company A, someone accidentally gave access to Paul Smith from another company. 

This reporting system actually showed who invested in a specific company. We should keep this data available only to the right people.

How do you prevent this from happening and at the same time provide all the flexibility for administrators? 

Usually people would come up with a process of double checking for example approving the permissions is done by some other people. Unfortunately this can fail because once these approvals are done routinely month after month and year after year someone will start doing it automatically without appropriate attention. 

I was not sure if there was any elegant solution but I stuck to my ropes and started writing Task Descriptions. 

I was writing a Task Description for granting permission step by step. 

Then it struck me. We could validate if the mail address of the user should allow him to see specific company data. Most people for a specific company would have the same domain address in their email e.g. lukaszpasek.com, google.com. 

I discovered an idea of whitelisting that is not very original and probably you know it. A whitelist is a simple matching of a specific company to a list of available domains. E.g. Alphabet would have google.com, Facebook would have meta.com, etc. 

Such a list won’t change often and you edit it very carefully. You would add domains usually only once when you add the company to the system. Having such a list we can very easily prevent granting access to company data to any people with emails which are not allowed by this company. 

Task Descriptions helped me to discover an elegant solution. I only needed to add one more Task Description: the one about editing the domain of a company.

Contact me

contact@lukaszpasek.com

About me

I have been a requirements engineer for 15 years.
I'm here to help you communicate software requirements.

Social Media

Strona www stworzona w kreatorze WebWave.