PITA. The abbreviation you shold always remember of when you gonna do these two functions well in one period of time. Pain In The Ass. This is the motto for your life when you are combining PM and BA in one person.
To make it more clear and visible, see the formulae below:
BA + PM in one person = PITA
There is a little story behind the PMBA experience. One girl dreamed of new job — Project Manager and Business Analyst two-in-one and, preferrably, in another lovely city that she was not origin from. By chance, she met her friend and accidentally an awesome IT company in the “best — ever-city” was searching for someone on the two-in-one position. An interview was good. People were awesome and a girl went to concuer new sphere in a new company.
My company has around 35 people, we develop on PHP, JS, we have mobile development and our projects are not as big as in the “big fish” companies — no investment banking, big medical or telecom projects, but new Airbnbs, products with gamification (btw, awesome ones) and others. Love it. Here I am sharing with you my BA and PM main observations. No rough insights but I would be grateful if someone has told me it before. Before I started.
Main Junior BA observations:
- it is awesome when your customer knows what he/she want and which TA the service will serve. Really. Not everyone knows it.
- do market research. Search for competitors. Direct and indirect. Investigate cases. Keep an eye on the best practices. Benchmark. If not for your customer than for yourself.
- educate your client. Tell him what is next. Tell him how you will work. Do not think that it is only the “sales function” to make an introduction to company. You are new to the client, he did not use to you, and he wants to see what is next.
- listen and talk to your client. A lot. As there are 2 main types of clients: those, who know what they want and those who don`t. In the first case you need to talk a lot to client to understand deeply business requirements and to communicate well your functional and non-functional requirements. In second case you need to see what really your customer wants and what is his need and to be rather a coach or consultant to form the product vision together. Be patient. In the second and in the first case.
- follow-ups. Only them. Believe me or not, there will come the day when a single missed follow-up will be the case in point. The wasted one.
- record Skypes, take notes. Always do this. There is a high possibility that you could miss something — so use additional brains-memos to keep in mind the crucial things.
- “close” questions. A moment in the requirements elicitation process comes when there will be “a question in the air” how to display those or that function and it is really crucial. In this case your job is to propose options but you need to choose one of them to move on. Ask customer what option to choose. Discuss. Persuade if you feel it is needed. Close questions.
- always do internal demos. You may tell me this is the case for PM. No, it is your responsibility, dude. You are the guy/girl in the team, who knows better how the product should work. And put off your “pink glasses” — your team knows only their module and only test specialist is the guy who also knows the product. But the responsibility for the product appearance is still yours. A tech testing guy may not know all nuiances and you may not documented it in SRS (as you, dude, still junior, remember?) so it is your final “pre-demo” where you could see your bugs too and fix it.
- Change Request is the holy idiom for the BA who works in the project on the fixed price. Why? You have your external customer who after each demo has a lot of “wants” and this “want” plus that “want” has a total of 10 something hours which may seem small tasks at first. 15 min. may turn to big time-consuming developing process so you need to balance between the “wants” which will make client happier and those which shall be paid. Change Request disciplines customer as he usually sees the price for the “want” immediately. At the same time this makes the client read the 50-smething pages Software Requirement Specification document just to see from the very beginning whether everything he or she wants is there (lucky you are if 50 pages).
- Do not panic, just do your job. For everything else read Karl Wiegers and BABOK. Peace.
Main Junior PM observations:
- learn JIRA. Really. From the very beginning. Take some time. Maybe a week and crack JIRA not to fall down in the eyes of your tech guys. And, when the desperation will cause tears on your eyes — remember: you should turn JIRA into your friend to manage the project successfully. It is like learning cycling — at first it is very hard, but some day you really need it to go for a ride with a great company. The same with JIRA — you may use your friend — Trello, but, when you will enter the higher league of project development you will see that JIRA is the shark you shall deal with.
- write a PM plan (project management plan)and send it to the client. PM plan has a lot of “healing” things: firstly, it structurized everything you will do — from the beginning to the Demo day — it is your plan, at first; second, PM plan gives you and your customer a common field of understanding — how you will work for the next X months and what to expect from you and your team. I`d rather call the PM plan the customer development thing. Though, important one.
- read Deadline by Tom DeMarco. It will save you a lot of time and will give you the sence how to behave and what to do in different cases. It is very sharp, not very deep and very good for general concepts.
- read “Scrum and XP — from the trenches”. I read this book after 1 month of my PM activity and I was really disappointed that I have not read it before. Either you are working on agile or waterfall — this book will give you a good sence of understanding the development process and it is up to you to make it better.
- do not panic. Your peers do not need to see you panic every time you tester tells you “we have got really HUUUGE problem” or you came into dev`s room and see that something is not working. Just try to understand what has happened and then try to react the situation with clear mind. No panic. Because you devs will panic too. Do you need it? (ok, sometimes, maybe)
- be patient about devs. Standups? They will miss them, you will need to notify them from time to time that “we have a standup” etc. But you could transform it to another way: I did it according to theory: what was done, what has to be done and which problems have occured the previous day and everyone seemed to be bored and did not see the profit for them (actually, I think that the main profit is for PM — to stay tuned to the project) BUT my colleague PM did it effectively — no standups — only sit downs and JIRA tasks distribution. But it works in our company — in your it may work in another way.
- keep the customer tuned about the project. If you need to delay Demo and thee is the possibility either to show it tomorrow or the day after tomorrow — choose the latest day. Be the pessimist here and prepare you customer to it and then, if everything works well — notify him/her that the problem was fixed earlier.
- control everything. CONTROL IT! Hey, did you hear? CONTROL THE PROJECT cause you are the PM! This was my mistake and there is no way to soften somehow the situation — maybe it is because lack of time (BA+PM=PITA) or because of incompetence but: you need to control mainly three things: cost, time and communication with client. The time developers are putting into TT should be controlled — you need to see where they put their time, analyze it and see the team`s velocity. Cost in the fixed price contract as vital to control as to count the seconds to open the parachute — one more second and the propbability that you will break down is higher and higher if not 100%. For small companies it is death. I would rather say that for companies with high amount of junior developers it is death. Communication with client is another thing. Here you are building the trust as you are in charge of the supervision of the development process. A customer has gave you the child to be raised (the project) and he expects you to take care of him and to tell whether there is a flu or he made first steps. Building good communication means building trust which will pay you off in the future.
- love the people you work with. Think of the people you are working with as the most bright, awesome and clever and they will behave so. But there may be exceptions. F*ck that and go on)
- choose your line of management — it can be dictatorship, liberal management etc. But choose it to be effective.
If you want to be a PM + BA please, think about it for a while. Do you really need the “crying nights” and days with this high pressure when 12 working hours are not still enough? Or, you are a kamikaze and you are taking another BA project and have these 24/7 working days when go home only to change clothes and to take a shower? I had the cases when I was twisted between JIRA issues and requirements elicitation for another project. At the same time, when you are BA, the BA artifacts consume a lot of time. Add to this all PM docs preparation — PM plan, risk log, all the reports etc. and you will receive the bomb which will explode in the form of missed deadlines, budget issues and problems with health.
Actually, when you are “in flow” — everything is interesting to you. When you are a maximalist — you believe you could do a lot. Believe me, you could not. You have physical and mental limitation and to perform better you need to renew yourself. Work does not need to take your these high efforts as it has another side — unproductivity. Care about yourself, manage your time and tasks and you will achieve success.