What to do when you discover crisis brewing?

Inspite of the best risk management plan that you and your team would have come up with, many small but important ones still slip through the gaps and raise their ugly head during the execution phase of the project. Whenever there is any risk foreseen, it is best to intimate the stake holders about the same so that they also adjust their view about the project. Some project managers think that they still have time to correct their course and wait and watch. They believe that if others come to know about the brewing crisis, it will portray a bad self-image. But later on when the crisis snowballs, and goes out of control, everyone comes to know about it anyway.

Here is what I think the PM should do. 

Intimate the stake holders on:

1.                  What is the situation

2.                  What could be the possible outcome of the same

3.                  What are the corrective actions that are being planned for it

Also it is good to ask for suggestions from the stakeholders.

Scrum

Scrum is a methodology to manage projects, which has come from the Agile Software Development stable. This is an approach where the entire team takes the responsibility to deliver the product. More emphasis is given to communication and the focus is on getting the job done. There is a Scrum Master who is akin to the Project Manager. He is the one who facilitates and removes all road blocks for the team. There are various terms one needs to be familiar with when following the Scrum methodology, like Srum Master, Srum Team, Scrum Sprint, Sprint Goal etc.

You can get more details regarding Scrum at the following links in wikiwikiweb and in wikipedia.

Scope Creep: Define boundaries

The problem with many projects is that the scope is not very well defined at the estimation stage. There are a lot of assumptions made and these keep the project boundaries very flexible. Many a times, the assumptions are not documented, and even if documented, they are not ratified with the client/business. In this scenario, a change in requirements, or a scope creep is even difficult to identify. Hence the pre-requisite to arrest scope creep is to know what the project scope is during the time of estimation.

Requirements from client/business always keep on changing. But whatever the project team has agreed initially as the scope should remain sacrosanct. Even if requirement changes keep on coming, they have to be treated as parked items and should be relegated to the next phase or taken up as a change request. The project manager should very diplomatically say no to scope creep and put it in such a way that it does not mean that he will not take up the work, but that he can take it up only when other project constraints like time, effort and quality are changed. The best thing to do is to lay out the options before the client and ask them to prioritize between different requirements within the project constraints.

What is the job of a Business Analyst ?

I have seen that in smaller projects, the role of a project manager gets diffused with that of a business analyst. Though a business analyst is not expected to do all that a project manager does, some of the work does get overlap. Here, I will discuss what the role of a business analyst is and what are the different expectations from a BA.

A business analyst is someone who assists in gathering the requirements from the users and present it to the technical team. The BA owns up most of the requirements management process. Since the users are many times, not very clear of their requirements themselves, and many times requirements evolve gradually, the BA is the person who facilitates the elicitation and documentation of the requirements. Sometimes, the BA is expected to put the requirements in the UML format and present it to the technical team. The BA is expected to have the knowledge of domain in which the application is to be deployed. The BA is expected to help the project team understand the functionality of the required application, test the functionality and also to assist the users conduct the UAT. The BA is expected to come up with status reports, coordinate among various stake holders and pitch in various other adhoc jobs.

BA roles are found mostly in those software companies which do product/ package implementation. In these cases, the BA is expected to understand the functionality of the product/package. The BA studies the current system which is called the AS IS state of the system and find the gap between the current state and the GO TO state. The requirements are communicated to the product/package implementation team which does the customization required to bridge the gap.

In some organizations, the BA role is confused with that of an application expert. My view of an application expert is one who understands the application in and out. This means that the person knows not only how the application can be used or is supposed to be used, but also knows how the application is structured internally, i.e, the technical details. In some places, the BA is expected to do market analysis, come up with ROI, do consultation work, etc. The skill mostly required for a BA is a deep understanding of the domain, a good knowledge of the product (in case of package/product implementation), good communicating, listening and negotiating capabilities.

I have worked as a BA in one of my previous avatars, and it was very satisfying. I could meet a lot of users, did lot of traveling, and explaining the users the product features, giving them solutions on how the product could be customized for their need, all the while feeling great as they thought that I knew the product in and out! Till about 4-5 years back, the BA term was rarely used. The profession had not gained recognition. Now, there are organizations like The International Institute of Business Analysis which support the BA profession. They are developing a BABoK, a book of knowledge for a BA. Please visit the site to know more about this beautiful profession!

Managing Expectations

A software project manager spends most of his time in planning, scheduling, reviewing, discussing, facilitating and communicating stuff done and not yet done. Proactive communication is one of the best tools a project manager has in his kit. This can be used to manage expectation of the stakeholders, i.e. the sponsor, the program manager, the project leader and the team members.

When it comes to making commitments, I feel that the best way to start is to under promise and over deliver.  Whenever a PM is called into a meeting with the program manager and client, there is tremendous pressure on him to agree to certain things, like scope, budget, schedule etc. In such cases, the PM should always try to set the correct expectations. Expectations set too low, will cause erosion of confidence of stakeholders on the PM. Expectations set too high makes the PM look over ambitious. Later on it adds to misery of the PM if that expectation is not fulfilled. So the PM should take care to set expectations correctly whenever he makes a promise.

Technical Project Managers

Are project managers required to be technically competent? Since technical competence is not a 1 or 0 thing, there is a continuum of the scale from being absolutely ignorant at one end to a master at the other end. Then there are shades of know-it-all PMs, but let us not get into that for now. So, how technically competent does a project manager need to be in order to be effective in his work? Is it that just a broad understanding of the underlying technology is sufficient or he should be some kind of an expert?

Really interesting. I think that among many other factors, this also depends on the size of the project. When the project size increases, the project manager may not be able to focus on multiple technologies. He may not be an expert of all technologies. In those projects, it is not possible to have a PM who is an expert in all technologies involved. The project needs to have its technical leaders as part of the core project group also.

What is the job of a Project Manager ?

Many a times I have thought about what exactly is the job of a project manager in software services industry. Almost all the software product development as well as service organization have this as a designation in their organizational hierarchy or as a role in the project teams. Sometimes, the role of a project manager is played by someone who does not have this designation. It is just a functional role. Whatever be it, the question is where does the role description start and where does it end? What is it that a project manager has to do and what is it that he/she is not supposed to do.

I have seen project managers who work  with their team members and help the developers debug their code, review the code, test the code and give functional help. Some also help in gathering requirements and managing requirement, which is mostly the job of a business analyst. However, their core job is to negotiate timelines with sponsor and draw the schedules & dependencies, manage risks, manage client expectation, prepare and control the budget and draw the project plan, allocating work to teams or to members depending on size of the team, participate in reviews, give presentations, manage people, manage team morale, enhance team members’ visibility in the organization, facilitate communication, keeps tab on the quality processes etc etc. They also prepare proposals and sometimes do estimations.

But then, even the project lead and the team (or module) lead also does many of these activities. Also a business analyst also sometimes does many of these things…So where does the role of a PM begin and where does it end? What do you think?

My opinion is that in smaller team size and projects, i.e, less that 12 member team, the job role of a Project manager is very blurred. When the project team size increases, more and more specialists are pulled in and the work gets distributed. That is when the job of the project manager gets defined in a clear cut way.

Some organizations also define a project manager as one who handles multiple projects or sub-projects. So as long as a person is handling only a single project, he is treated as a Project Leader. What are your views on the same?

Other Project Managers :

Subsequently, I was fortunate enough to work with project managers, who were nincompoops, who faltered in everything they did. They were the ones, who just left things to take care of themselves, blissfully ignorant of the increasing entropy in the system. Very soon, projects begin to drift and appeared to be out of control. Actually, they were never really in control. The project team members neither had respect for them nor took any of their words seriously.Then there were others, who were simply brilliant. Most of the projects they handled were completed successfully. Team members just enjoyed working with them. There were many who were in between these two extremes.

But then there were some who had the world-view that Project Management is nothing but politics. They excelled in their job by manipulating resources including people. They also seemed to get the job done bypassing everything in the rule-book and inventing and living by their own rules.

There are many different ways of managing a project and the art of project management is followed differently by different folks.  I am still searching for the best combination of skills and temperament for this art. I am sure you also would have come across many project managers, some whom you would have enjoyed working with, some whom you did not like...what have been your experiences of working with different project managers?

My First Experience with Project Managers

When I joined my first job in a company as a fresher, I was always in awe of my project manager. He was a man young of years but old of wisdom. He was someone, who commanded respect by virtue of his way of handling people and things at work. He seemed the perfect gentleman to me. Always a smile playing on his lips, he was soft spoken, process oriented and also an expert in the domain. He used to get things done and received many accolades for them. Since we were working in a production support and maintenance environment for a credit card application, the work pressure was often too high. We worked together for some about 6 months in which I learnt many a things from him. What I liked in him was his ability of never loosing his cool under any situation. I considered him to be my first mentor and when I wanted to make a career move, I consulted him.

Then, my project manager changed and a new person replaced him. His style of work was totally different. He also used to get the work done, albeit in a different way. His philosophy in life was to work hard and play hard. He used to take the team out many times, of course on his own expenses and, the team loved it. Guys in the team also repaid him back by working hard. Of course we were all bachelors at that point of time and then it did not matter if you hit the sack at home or in the office.. That was the summer of 99'!

Impressions

As a young professional who joined the software industry more than 11 years ago, my dream was always to become a Project Manager. So I keenly watched all my project managers with whom I had the good fortune to interact with. I am glad that I learnt many things from the good ones and even more things from the ones who were not so good, especially what and how not to go about managing projects.

I will start this blog on Project management with my experiences of working with project managers having different styles .. My experiences and thoughts of managing (and mis-managing) projects.