Notion – an all-in-one workspace

Today I came across yet another interesting application – Notion. It can be a simple note taking app just for yourself, or a collaboration tool for a whole team, with knowledge base, tasks, and project management. There’s also a way to have other types of structured data, like CRM leads, etc.

I wish I had the time to play around with it right now, but I don’t. So I’ll leave it here for the next time.

P3.express – practical project management framework

When it comes to project management, there are many certifications, guidelines, and suggestions all over the web. But it’s often difficult to pick the right one. Some are overly complicated. Others are too simplistic and don’t cover even the whole project lifespan.

P3.express, however, looks good. It covers the project management process from the early days, when it’s not even clear if the project will proceed at all, to the tasks that need to happen after the project has been fully completed. The whole flow consists of 37 activities in 7 sections, with each one of the activities being well documented and explained.

This one is definitely worth a try. Especially if you ever felt like this:

OPP – Other People’s Problem

I really liked “OPP (Other People’s Problems)” article which talks about handling of responsibility for things that other people should be responsible for.

If you’re reading this looking for advice, you’re probably a go-getter. You consider yourself a responsible person, who cares deeply about doing things right. Your care may be focused on software and systems, or on people and organizations, or on processes and policies, or all of the above.


This attitude has probably served you well in your career, especially those of you who have been working for a number of years. You’ve been described as having a “strong sense of ownership,” and people admire your ability to think broadly about problems. You try to think about the whole system around a problem, and that helps you come up with robust solutions that address the real challenges and not just the symptoms.


And yet, despite these strengths, you’re often frustrated. You see so many problems, and when you identify those problems, people sometimes get mad. They don’t take your feedback well. They don’t want to let you help fix the situation. Your peers rebuff you, your manager doesn’t listen to you, your manager’s manager nods sympathetically and then proceeds to do nothing about it.


That kind of grinding frustration can wear you down over time. I know, because I’ve been there. 

Not only the article describes the problem, but it provides a practical approach to dealing with it.

In the last few years, I was going through a very similar thinking process in my head, but I’m nowhere near the well-defined suggested approach. I wish I read this much earlier in my career. Much much earlier.

Why software projects take longer than you think – a statistical model

Why software projects take longer than you think – a statistical model” is an interesting take on the problem of bad estimations in software projects. I’m not that great with math, but even then the article is very interesting. And there is a lot that I agree with.

Here’s a quote for those of you who couldn’t make it through:

Why software tasks always take longer than you think

Assuming this dataset is representative of software development (questionable!), we can infer some more numbers. We have the parameters for the t-distribution, so we can compute the mean time it takes to complete a task, without knowing the σ for that task is.


While the median blowup factor imputed from this fit is 1x (as before), the 99% percentile blowup factor is 32x, but if you go to 99.99% percentile, it’s a whopping 55 million! One (hand wavy) interpretation is that some tasks end up being essentially impossible to do. In fact, these extreme edge cases have such an outsize impact on the mean, that the mean blowup factor of any task ends up being infinite. This is pretty bad news for people trying to hit deadlines!

Redmine: Estimated Time as mandatory field

At work, we are using Redmine for all our project management needs. It is a flexible and powerful system that allows flexible configuration for the processes of most companies.

Recently, we have decided to make the Estimated Time field mandatory for all the tickets. Configuring this turned out to be trickier than I thought initially. I couldn’t find the option to do so on the first go.

Some Googling around suggested that Redmine’s source code needs to be modified for that. Not something that I wanted to do. And the tip is also from 8 years ago, so it’s probably quite outdated.

After digging deeper, I found a way, that doesn’t require source code changes. This can be accomplished via editing the Field Permissions in the Workflow. Here’s the process (for Redmine 3.3.0 stable, that we run currently):

  1. Login to Redmine as administrator.
  2. Navigate to the Administration screen (a link in the top bar or so, depending on the skin you are using).
  3. Navigate to Workflow.
  4. Switch to Field Permissions tab.
  5. Select desired roles and trackers.
  6. Press Edit button.
  7. Scroll down to the Estimated Time field.
  8. Select Required from the dropdown for each status, as needed.
  9. Press Save button.

You are all done. Now all tickets of the above selected trackers will require the input of the Estimated Time for all above selected statuses and roles.

Similarly, you can make other fields required or read-only, as per your company or team needs.