How to handle software project pressure – Part 2

Part 1 was pointing out what outside factors are in your control and make your life easier if you are working in high pressure project. This part 2 will point out some ways for PM's (project managers) I find elegant. I see basically 5 areas under the control of a manager that are having the biggest impact on software project pressure:
  • Project Management
  • Information Management
  • Resource Management
  • Expectation Management
  • Feedback Management
 

Project Management

There is a good reason why every point is having the word management in it, because this is what a PM should do: Managing. Sometimes PM's think they have to take care of everything, even things that are not in their hands. You are not a developer, you are not a Tech Lead, you are not a network administrator and also not a security or quality assurance expert. I see this as a very common reason for stress. Your task in this equation is to inform all of them what the project needs, and keep track of the status. Also it is not your job to bring others into stressful situations. The opposite is true. Manage to not have stress.  

Information Management

Facts Facts and Facts again...delivered with good timing. This is what is needed to bring a project to a successful end in time. So the first thing to do is to figure out what information is needed. Then you need to figure out who can give you this information where you can rely on. Sounds simple? Sorry it is not. Getting all information is a very hard part. I saw it in every company on every level, information management is the most complicated thing if you have more than 100 people working in a company. Where you should focus on early are things like:
  • Who will use the system?
  • What already existing systems are connected?
  • Is any department permitting the usage of the system?
  • Was there already the attempt to have such a system?
  • Are there dependencies that can change without your notice?
  • What is the short / medium / long term plan for the system?
  • Is there any legal issue?
  • Is there a commercial tool available for the same purpose already?
  • Do I need experts that are not available in the own company?
  • Are other companies using such a system for the same purpose?
  • What time plan do you have?
  • Who are the shareholders?
  • What key functions should the system provide?
  If you have answers ready for this you can start working on details. With details I mean giving specific tasks to your team. If you cannot clarify all these questions you might need to pay a high price in the middle or end phase of the project. This leads to stress. So get your hands dirty and talk to a lot of people, especially to the ones you would not expect that they have something to-do with the project as I wrote in my "How to ask good questions article". Then write all the answers down and inform all parties. Make a kick off meeting and bring them on the same table. Then decide the firsts actionable steps.  

Resource Management

After you are having clear information available get together with your team and estimate the effort it will take to realize the project. For this you need a very detailed plan of the steps. So start backwards. Image the finished project and look back what is needed to get there. Use a simple table with the columns "Task" "Importance" "Complexity" "Resources" and start with your team together! Here you should note down details like "Customer Registration Logic, High, Medium, Developer xyz" or things like "24 Login Monitoring, Medium, High, Developer yxz + Sysadmin abc". One moment please, is this waterfall? Yes, it is. But we want to be agile, we cannot use waterfall. I understand and yes you can and you must. But not the whole time of course. The thing where you need a waterfall like plan is for the must haves, the big things. They need to be on time and software systems do not care in which way the creation of them is done. If the function is not implemented, because it was not aligned with other departments 2 months earlier that you need to change process yxz, it will not work. You cannot charm a computer by saying that you where using agile methods only and that's why he needs to do this and that, only written code can. So here you have the information and based on this a plan for the project task. Now add a column with the prioritization. I recommend to start with the most important things and also with topics where you have the highest level of certainty that you know enough to start with. Put the highest priority on them. If you are not sure if the feature will change then do not start on it if there are other things to do that are more stable. If you do it the other way, the time lost will bring you into trouble for sure. Now talk to your team and all people you need, how much time it will take to do the actionable tasks. I recommend to always use a factor of 1.5 to it. I rarely saw a project ready on time so get yourself a buffer. One important thing I almost forgot, non-available resources or information. There are some points in a project plan where it is almost impossible to estimate the effort or where it is not clear if there are all resources available. Maybe you need to hire a expert especially for this. Make this visible.  

Expectation Management

You have a plan in your hands what you plan to do and when. Now let's communicate it to the shareholders. Tell them what feature will take how much time. The reason for this is to align between their demands and what you can deliver to them. They need to know what is difficult to do and what is easier. Also the topics you think are important might be not so important anymore if they need to wait another month or two for it to be available. Use this way of open communication to adapt priorities and figure out where the real hard deadlines are and where there is some room you can play with. And as said in the last capture, communicate uncertainties and ask them actively for support to get more clarity. A good shareholder wants the stuff getting done and he will reward you if you are supporting him in getting what he wants. After all of you are on the same table inform the whole team on the commitment and begin with the actual work.  

Feedback Management

What is the number one reason to risk the support of your boss and increase stress? I think it is bad information and feedback management. When projects are at risk regarding timeline and realization capabilities, I would be so not amused if I get to know this at the end of the planned timeline / deadline. So my approach on this is to keep all people that are planing with the project I am involved in up to date. It is not needed to tell every detail but the overall status needs to be communicated very clear. I would also always announce it to the people in person if stuff is not working out in time and look for ways together, to still achieve a success. This is very strong connected to expectation management. If you tell what the status is early, you see that this keeps pressure from your shoulders a lot. It might be also the best way to ask for more support and resources to get back on track.