Archive for February, 2009

Collective Project Planning

February 26, 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.

This sort of teamwork will help in

  • identifying the scope of the project,
  • increase the team’s morale,
  • set the expectations at the beginning of the project,
  • restore confidence in the team,
  • de-risk the project
  • make the team feel involved in the project

The sucess of the project is thus much more assured.

Role of Business Analysts in Projects

February 25, 2009

Wikipedia states that

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.

P.S. – The International Institute of Business Analysis provides a certification program for business analysts (Certified Business Analyst Professional or CBAP), as well as providing a body of knowledge for the field (Business Analysis Body of Knowledge or BABOK).

Software engineers have to be taken care

February 23, 2009

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.

Maslow's Hierarchy of Needs

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.

Project Communication Process

February 17, 2009

Communication – definitely the oldest method of passing information from one person to another or a group of people.

In Software Development, communication between the various stakeholders happen in various means:

  • Daily Chats between project team members and customer team, either by mail or IM
  • Formal Status Meetings between the Managers on both sides (Customer and Project teams)
  • Regular Steering Committee meetings between Senior Managements of both teams

All the above-mentioned means are those which involve interaction of personnel of both teams.

The other mode of communication is via documents. There are different types of documents that are produced by the various teams involved in a project

  • Requirements like Software Requirement Specifications (SRS), Use-Cases
  • Architecture like System Analysis and Design(SAD) document
  • Design like UML documents
  • Development like source-code
  • Testing like Test Plans, Test Cases
  • Management like Project Plan, Project Status Reports

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?

Enter Web2.0

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
  • Whiteboard communication sites like Twiddla
  • Project Management tools like dotProject, Project.net and more
  • Document Management tools like Alfresco
  • and many more…
  • 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.

Importance of Estimation in Software Development

February 16, 2009

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.

In a RUP project, the estimation is mostly done by 2 methods:

  • 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.
  • Ensure that you have covered all the corners –
  1. Have you included testing activities also in the estimates?
  2. Have you left enough time/resources for documentation?
  3. Are there any interfaces present? How are you taking care of them?
  4. What is the level of detail you have taken for testing activities? Have you included all the various types of testing?
  5. Have you included Warranty Efforts also?
  • 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 🙂

P.S. – Noticed a good article introducing the concepts of Function Points by name Introduction to Function Points.


%d bloggers like this: