Attitude versus Knowledge

In one of my discussion with a project lead, we were debating which is the most important attribute of a team member. The project lead, who was very much bogged down with the knowledge level of the team members was rooting to the fact that knowledge is most important factor when choosing a team member. I begged to differ. My point was that knowledge can be acquired by a person with the right attitude, but a person with requisite knowledge but lacking in attitude can be a nightmare for any project. If a person has the attitude to learn, to work hard and takes his job seriously, he can compensate for the lack of knowledge in the short run, and on account of his being a learner, will be able to catch up the knowledge in the medium run. Of course, the project duration is also a very important factor in this. For shorter duration projects, which are less than 3 months, the team member has to be knowledgeable so that he can hit the ground running. There is no room for anyone to learn in short duration projects. But for longer duration projects, I would rather choose people with the right attitude and train and build their knowledge. This way, the team member also does some value add to his own skillset and the project also benefits.

Project Beginning and Project end

I have observed in many of the projects that there is a lot of management focus while the project begins. But as the project comes towards the end, slowly the focus of the management drifts to other issues and other high priority projects at that point of time.  The highly skilled resources and dynamic project leads are slowly pulled out because of their requirement in other projects which necessitates the second in command to step up into the higher role. There are two sides to this.

For the second in command guy who takes over, there is an opportunity to showcase his skills. Thus he gets the benefit of leading a team. And in the way, the management also discovers some budding talent. But this approach may also lead to disastrous situations if the second in command is not capable enough. Though there is a school of thought that, there should be continuous management support and attention for a project from beginning till end, real work and business life priorities necessitates to make such changes and we have to learn to live with the change!

Celebrating at end of Project

“All work and no play makes John a dull boy”

There should be some kind of celebrations at the end of a project and if it is a large project, then probably at each milestone reached.

I have found team outings/celebrations, apart from creating a sense of feel-good factor among the team members, also help in team bonding. People get to know each other better in an informal non-work related setting. We have had scenarios where given a choice, the team members consider these as part of the hygiene factors to decide whether to be in a team or not. They compare how often their own team has these good times vis-a-vis other teams.

In one of my project which was a maintenance and support type of work, there was no end at all. The project always kept on going.  One request closed, 2 more were open. People never had a break. There was no end. Also you cannot be partying at every request that is closed. Other teams which were involved in regular development work, they used to have the ending rituals as their end was very well defined.  We decided that in order to overcome the issue of not having any ending, we will have parties or outings every two months. This helped in keeping the team morale high and everyone happy.

Another reason to have these informal lunch party/outings is that it is a good way to gather feedback about the project as well as feedback on a personal level also. Everyone benefits!

Perception Management

I had a manager who used to say, “Perceptions are reality unless you change it”. He used to say that if someone perceives you as a poor programmer, even though you yourself might not think so, you remain a poor programmer, unless you proactively do something to change the other person’s perception. And this is not limited only to perceptions regarding people. It is also true for projects!

We had a peculiar situation in one of our projects. The project was running its normal course and as usual towards the end of the project, there were a few loose strings to be tied up here and there. However, that simple issue had somehow got ballooned up in the mind of the client and created the perception that there is a crisis. Escalations were done and after of lot of management attention, everyone realized that it was a non-issue! It was just that the perception of the client was different from what was the ground reality. And the ground reality was that the project was scheduled to meet the target date.

Hence, apart from client expectations management, we need to manage the perceptions of the client also. This will save a lot of time and effort in firefighting for an imaginary fire and convincing the client!

Quality of Human Resources in a Project

Sometime back, I read a blog stating that everything that goes wrong in a project can be traced to a commitment made by someone at some point of time. This is quite true. Let me share one experience with you.

In one of my previous projects, we found that the quality of resources that we are getting to staff the project was of very bad quality. Some resources were taken on board without having in depth technical know-how. This was not very apparent in the initial days of the project. But as the project progressed, there were certain team members whose efficiency was questioned. The project seemed like moving towards failure. Top management stepped in and tried to augment the resources. Experts were called in. After months of late nights and mail fights, somehow the project was completed.

Now, it was time for introspection for what went wrong and what went right. Though people were groping in dark to figure out what went right, everyone was sure of what went wrong – Not having the right people. It was written down and notes circulated and presentations made. The blame game continued. People were crying for the throat of the HR team which had staffed the project. Some were saying that the quality of input deteriorated because the screening was not good. All guns were pointed to the HR folks and their processes. But the trace back does not end here.

The question is why did the project staffing folks get such guys in the project? This can be traced to the discussion which happened between the project manager’s boss and the HR manager. The organization had got a huge project and the manager wanted to complete it within a specific time. The sales folk had committed that they can do it. They had revenue targets to meet. No one really focused if the organization had the required number of resources with correct skills. With the deal sealed and contract signed, the delivery date was fixed. Now a mad scramble begun for resourcing. Rapid action teams went out to scout for talent. They had their targets to meet. So they got whoever knew how to spell the language and asked them to work on the project… and the project was doomed for you know what…

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.