Tag: management

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!

PHP CEO on Twitter

@PHP_CEO is a new corporate humor goldmine on Twitter. It’s very much like I am a developer, but, you know, from the CEO perspective.

Some of those tweets are nothing short of brilliant!

NASA: 100+ Lessons Learned for Project Managers

Jerry Madden, the former Associate Director of Flight Projects at NASA Goddard Space Flight Center (GSFC), collected 122 lesson learned nuggets from a variety of sources that are instructive to managers of NASA spaceflight projects.

While these are mostly around NASA projects and problems, many are very applicable outside as well.

Here are a few to get you started:

  • Don’t be afraid to fail or you will not succeed, but always work at your skill to recover. Part of that skill is knowing who can help.
  • Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will.
  • Reviews are for the reviewed and not the reviewer. The review is a failure if the reviewed learn nothing from it.
  • Mistakes are all right, but failure is not. Failure is just a mistake you can’t recover from; therefore, try to create contingency plans and alternate approaches for the items or plans that have high risk.
  • The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they are in trouble. Engineers are born optimists.
  • Software now has taken on all the parameters of hardware, i.e., requirement creep, high percent-age of flight mission cost, need for quality control, need for validation procedures, etc. It has the added feature that it is hard as hell to determine it is not flawed. Get the basic system working and then add the bells and whistles. Never throw away a version that works even if you have all the confidence in the world the newer version works. It is necessary to have contingency plans for software.
  • Reviews, meetings, and reality have little in common.
  • You cannot be ignorant of the language of the area you manage or with that of areas with which you interface. Education is a must for the modern manager. There are simple courses available to learn “computerese,” “communicationese,” and all the rest of the modern ese’s of the world. You can’t manage if you don’t understand what is being said or written.
  • People who monitor work and don’t help get it done, never seem to know exactly what is going on.
  • There are still some individuals who think important decisions are made in meetings. This is rarely the case. Normally, the decision-makers meet over lunch or have a brief meeting to decide the issue and then (at a meeting called to discuss the issue) make it appear that the decision is made as a result of this discussion.
  • Management principles are still the same. It is just the tools that have changed. You still should find the right people to do the work and get out of the way so they can do it.
  • Integrity means your subordinates trust you.
  • There are rare times when only one man can do the job. These are in technical areas that are more art and skill than normal. Cherish these people and employ their services when necessary as soon as possible. Getting the work done by someone else takes two to three times longer, and the product is normally below standard.
  • Never assume someone knows something or has done something unless you have asked them. Even the obvious is overlooked or ignored on occasion– especially in a high-stress activity.
  • A person’s time is very important. You must be careful as a manager that you realize the value of other people’s time; i.e., work you hand out and meetings should be necessary. You must, where possible, shield your staff from unnecessary work; i.e., some requests should be ignored or a refusal sent to the requester.
  • The project manager who is the smartest man on his project has done a lousy job of recruitment.
  • Never ask management to make a decision that you can make. Assume you have the authority to make decisions unless you know there is a document that states unequivocally that you cannot.
  • The boss may not know how to do the work, but he has to know what he wants. The boss had better find out what he expects and wants, if he doesn’t know. A blind leader tends to go in circles.
  • In political decisions, do not look for logic– look for politics.
  • Too many people at Headquarters believe the myth that you can reduce the food to the horse every day till you get a horse that requires no food. They try to do the same with projects, which eventually end up as dead as the horse.