Monday morning – I open my email and see an email from Tim, business analyst hey saying “Hey AKASH we have bagged another Mobile application project and by the sounds of it, is going to be the next big thing”. The e-mail gave tears of happiness to accounts team, the sales manager and business development manager. I was also in tears but not happiness but what I call is tears of fear. To be very honesty every project manager gets those tears of fear irrespective of the experience they have in their pocket.
Being a Project management consultant for years I have heard several questions from project managers regarding managing multiple projects, So I thought it would be a good idea to post it on my blog.
Following are some of the actual questions I have heard.
“How to manage multiple projects at same time”
“What is the standard in the industry for managing multiple projects”
“How do I find that I am not overwhelmed by multiple projects”
To me management is a trait and everyone could not be as good as someone born with this trait. It is same like, some are born musician and someone else could learn it but its hard to beat one who are born with it. Its hard to say how much projects you could manage at same time or whats the threshold. Its totally upto you. You could increase your productivity by avoiding these mistakes for sure.
There is an old saying, which I guess everyone must have heard it before. The saying is “Learn from your mistakes”. Never knew that this saying which I heard from my grandma will be an important part of my project management and business analyst career. On the other side PMBOK actually clearly specifies it as a best practice. PMBOK says to document the lessons learnt for each project and make it accessible to other project managers as well for future use. So I am following the code of PMBOK and writing all the things that I have learnt in my career as a business analyst, developer and a project manager. You can call them as lessons learnt or best practices, but I prefer to call them lessons learnt as these things I have learnt on my own as I am not as smart as CHUCK NORRIS.
If you would have served as a business analyst or a project manager you know the importance of workflows. Coffee/wine loaded client meetings (if you are not using cisco webex or skype) you jot down each and every point of discussion, record the session but in the end when you try to do the knowledge transfer to your team errrrrrrrr.. That is a situation every analyst faces or has faced in the past.
In last 4 years I have worked in different roles, I have moved from being the database guy, then the core I.T. / Programmer to a management person. That core experience has given me a lot of insight and an upper hand in my role as an analyst and a project manager when compared to managers who just came out of school with their MBAs. I find myself better with understanding the requirements of the clients, creating the charter with team, creating the Work breakdown structure and assigning the team/resource to those tasks.
As we all work in an environment where we are responsible for tasks that we perform, we might also be accountable for those task/s. We might be consulted in for a task or two or might just kept in loop for some tasks. This when tabulated in a sheet is called the RACI matrix pronounced as RACEY or it is also called the resource allocation matrix (R.A.M.)
Every company’s nightmare SCOPE CREEP. If you have been a business analyst or a Project manager then there is no point in your career that you have never dealt with SCOPE CREEP. If you are a new business analyst or a small development house then in a nutshell SCOPE CREEP is change or growth of project scope.