Archive for February, 2009

Project Planning forms an important part of Project Management. This is the phase where the Project Manager, with the help of Gantt charts, comes up with a schedule in which the application (proposed) can be built. Of course, it is not an one-off event – it happens till the end of the project. There are numerous planning (and re-planning) activities done by the Project Manager throughout the project.

The deliverable of the first few iterations of the Project Planning activity is the Project Plan. The Project Plan will contain the various activities that need to be done by the different team members on specific days as mentioned. The Plan (in its best optimized version) will show the daily schedule for each team member and the expectations that the Project has, from him.

For the team members to accept this plan, one of the suggest approaches is to have the team also part of the planning exercise – not all the team members but definitely the critical and senior ones. The team has to feel comfortable about the plan before they start. Or at the least, the team needs to know that they are getting into a project with strict deadlines and be prepared accordingly.

The Project Manager has to play the role of a moderator, who gives the background of the project, the organization’s view-points of the project, the constraints that the team has to work with. Once he has done this, the team should take over the exercise of coming up with the activities involved, sequencing them, assigning a duration (arriving at the estimate to start with), discuss any risks that they foresee in the project. This should be done at the beginning of the project so that the team knows the target that they are looking at.

A business analyst or “BA” is responsible for analyzing the business needs of clients to help identify business problems and propose solutions

BA plays an important role in any software development project. He is the one who is expected to liaison with the Customer team and conceive the application that has to be built. They act as the proxy Customer for the development team.

Sometimes, it feels that a BA might be redundant in a development project. For example, a website development project. The amount of domain maybe relatively less as compared to a financial services product or an online banking application. These projects might be successful even without having a full-time BA deployed on the project. But, this does not mean that the functions typically done by a BA is not required – this might be taken up by a person who is playing an equally important role (Architect or Technical Lead)

The deliverables expected from a BA is typically

Functional Requirements

Non-Functional Requirements – this is arguable as the Architect also gets into these discussions mostly

Mock-up screens (or Prototypes) – this will let the team know how the screens have to be developed. What are the field layouts?

Test-cases – this is sometimes not explicitly mentioned but a very important responsibility. Since the BA knows about the functionality of the application, it is essential that he reviews the test-cases also.

Of late, the role of BA in a project is evolving. They are expected to carry the functionality and know technical aspects. Hence, the role of a BA becomes as critical, if not more, as that of an Architect.

SOA has given a new meaning to the BA role. Since SOA revolves around using and re-using Business Services, it makes sense for Business Analysts to have proper understanding of the technical jargon as well as the functional domain. This way, the services can be designed to provide maximum reusability across any organization.

Does it mean that BA’s have to be specific for a domain? Should they concentrate on one domain for the rest of the career? The answer is YES. This approach will ensure that they will have a focused path ahead of them. They can master their domain and get more insight of their focus of work.

Thus, Business Analysts have a critical role to play in the development projects – the level of their understanding of the requirements from the Customer will determine the completeness of the final application.

Like this:

Motivation is the set of reasons that determines one to engage in a particular behavior, as per Wikipedia. Without motivation, humans do not get the impetus to achieve anything in life, let alone career. In a software career, they have to be motivated enough to give their best on development projects – I am not here trying to give the idea that they need to be pampered. All I am saying is that the Project Managers need to understand that each team member is different from the other and hence, they need to be motivated differently.

Abraham Maslow had an interesting theory – Hierarchy of Needs (proposed in 1943!!!) which is very adequate – proof that the basic characteristics of humans have remained more or less similar in the last 70 years.

Hierarchy of Needs

It would be a good idea for the Project Manager to find out where his team members (the ones that report to him) stand in the Hierarchy. Based on the position, the Manager would be able to find out the strings he needs to pull, to get the best out of his team. If a developer is feeling insecure about his/her job, the Manager can have a one-on-one discussion, make the developer feel comfortable in the team. The PM can meet the developer on a regular basis, giving him the assurance so that the doubts can be erased. Similarly, the architect might have a feeling that he/she is not respected in the team. By bringing out the good deeds done in an open team meeting, the PM can give the confidence of the architect a big boost. This can be then replicated by his reportees (probably Team Leads) on their teams and so on.

Why is it such a big deal? Let us face it. A team member who is not motivated is one who can make/break the project. One bad apple in the team is capable of influencing the others in the team as well. Hence, it makes it all the more important for the Manager to take good care of his team.

These documents help the project teams get a common understanding of the area under consideration.

The documents are usually stored in a common location (Project Folder or Version Control System) and accessed by both teams (who are located in different cities mostly). Some projects tend to share these documents by email and thus, lose the version-control. To avoid this, projects use software tools like

This is definitely huge amounts of data that is shared between the teams during any development project. What typically happens to project team members is that they miss out on any new communication that is very essential to them? If one member gets the information, by mistake yet another team member might not get the same. How does one take care of these situations and avoid ugly scenarios in the project?

It is very easy to use the technologies of the current fad in project development for ease of use.

Wikis – these can be used for creating documents online – no tension of overwriting conflicting versions, collaborative creation and review of documents. These can replace the Word documents that are bandied around between offshore and onsite teams.

Folksonomies – These can be used to share best practice links between Architects/Designers and the developer community (like sharing links on delicious)

Skype/Google Talk – can be used to talk (rather than chat) with remote teams for issue resolutions/clarifications instead of the usual spreadsheet communication

Portals – these can be used to aggregate all the tools mentioned above so that the project teams can access one url for getting all the information required. Examples of Open-Source Portal software are Liferay, JBoss

These technologies do impact the communication process of software projects in a big way. The confusions that remain between the teams can be removed if the data is shared. This is definitely the way to go, for project communication, in the Web2.0 Age.

The most important component of Project Planning is Estimation. Estimation of the Work involved will give the Project Manager a sense of the magnitude of work required to be executed to get the expected application built.

As mentioned earlier, scope is very critical for the success of a project. Once the scope has been frozen (or at least prioritized), the estimation plays a big role in determining the efforts required for development and getting the team members finalized.

CoCoMo – Historical data plays an important role to find the accurate estimates for the new projects. Fine-tuning will be done based on the project-specifics.

Function Point Analysis – The software is divided into a number of function points, each having their inputs, outputs and processing factors. Other environmental characteristics are applied to get the final estimation.

Following these methods will give you an accurate estimate for your project, right? Not Always. It depends on the specifics of your organization, the team that you are planning to induct, the customer’s organization, the overall goal, constraints that have been (or not) considered. So, how do you validate your estimate?

Do a quick and dirty estimate by another methodology. If you have done it using CoCoMo, do one using FP

Have a review done by a Senior Manager (if it is a strategic project, get it done by your boss) on the estimates. Explain how/why you have arrived at a given estimate and the details. This will help him (and yourself) validate the assumptions that are taken into consideration.

Include all the ‘Expectations‘ for ensuring that the estimates stick to what you have come up with. For example, you might expect a web-service to be already available for a function. If this assumption is wrong, you will end up writing the web-service (for free)

Include all the risks that you see in the project. Any change in risk status, will also affect the estimates.

All these points will ensure that your estimate is close to what will be comfortable for you to implement the project. Then, all that is required for you to do is to Pray and Wish it is true 🙂