Project Management Software
Specialists in Project Infrastructure
This document is formulated with experience gained from recent offshore software project work based on agile methodology. It describes observations, which could be used by anyone considering exploring offshore development. It also provides information on what to look for when selecting an offshore vendor.
Agile methodology is a relatively new lightweight methodology and is looked upon by many companies as the way forward in software development. When compared to traditional methodologies, agile provides a practical approach to software development which takes the changing nature of the business environment into account. The main aspects of agile development are about increased speed of development, less time-to-market, quality, efficiency, and management of the impact of change.
Customer satisfaction is a great concern in all industries, to survive and be ahead of others in this current trend of globalisation. Companies are competing at different levels to achieve a bigger market share by improving customer satisfaction, and strongly focusing on the deciding factors such as competitive pricing and quality, via the use of technology.
In order to be price competitive many companies from the western world are exploring the options of building their software products offshore to cut down on cost. This has made offshore software development a hot and attractive topic these days. Although, offshore projects have been quite attractive, many of them have failed to yield the expected benefits mainly due to poor or lack of project management rather than technical know-how.
The sections below describe each of the above factors in detail.
Understanding the Offshore Challenges
The main challenges faced when off shoring are the distance, culture and time, which create hardships for a smooth offshore operation. A good understanding of the above challenges will help to alleviate the risks completely or reduce them drastically.
Culture and Language Barrier
Culture is a complex and an integral part of our lives, which we have learnt over the years and practice on a daily basis. It is the values, beliefs, behaviour, morals, and law of a society, which makes up this culture. Culture has a significant impact on countries, companies, employee ethics and intra employee relationships, which could lead to several issues in offshore development.
It is easy to find technical experts in the outsourcing world, but the question is do they understand the cultural importance of your product? To what extent do they expect you to describe the requirements, even if they have experience in your industry?
Some of the cultural issues I have generally come across are:
Communication plays a vital role when dealing with offshore projects. English is mostly the common language for business dealings. Although English is spoken in many countries, English is not the same English everywhere, due to different pronunciations, and slang which makes understanding really difficult. To overcome this problem I have noticed many companies formalize communication with detail documentation and formal processes; some take this way too far. Although this works, I find this too costly, time consuming and it makes maintenance really difficult.
Multiple Time Zones
Imagine when you come into the office; your colleagues at your offshore cent er are packing up to go home; or imagine having offshore cent ers in several countries from different time zones, rather than in one. There is no solution to resolving this time issue, and the only way is to work with it. The impact of this issue should be born by both parties, and it should not be expected that it will be absorbed by one side only. Of course the situation is not as bad if the time difference is less. This is the case between European countries and Asian countries like Sri Lanka and India.
Several measures can be taken to reduce the impact caused by time zones; some companies have mutually agreed on an acceptable time with their offshore partners for online meetings and phone conferences. Others work according to the client’s time during critical deliveries
Although time zones has its negative sides, some companies are found to make use of it as well, by round the clock development. This is achieved by working with the offshore partner on a shift basis.
Lack of Visibility and Multiple Locations
Due to dispersed or multiple locations, keeping track of projects become a real challenge, in terms of keeping up-to-date with the progress and risk factors. Imagine a situation where the vendor, based on their evaluation mentions 80% of work is complete for a certain module. This, from a client’s point of view, would have no meaning and there would be no means of verifying the above figure, due to the intangible nature of software. This often creates uneasiness among the clients.
Need for a Methodology that Works
Introduction to Agile Software Development Methods
Software development has been around for many years, and has evolved significantly, to keep pace with:
In order to cope up with these changes, software development methodologies have been under constant scrutiny and research. They have striven to identify effective and efficient processes for delivering projects successfully within specified and tolerable resource limits.
Most of the current (traditional) software development methodologies have been in existence for many years, and have been difficult to put into practice in real life projects. According to Pekka Abrahamsson in their book on Agile software development methods, the traditional methodologies are not used in practice and that they are too mechanistic to be used in detail. With the shift towards offshore development and the requirement for faster development cycles, the traditional methodologies don’t seem to deliver results to satisfy the modern day stakeholders.
From observation, the agile concept seems to work well for current day requirements and challenges, and is an effective and lightweight software development model. It is based on a collection of values, principles and practices. As described in the agile manifesto, the values of agile software development are expressed as;
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value
That is, while there is value in the items on the right, we value the items on the left more.”
The principles followed by the agile manifesto are;
Therefore in summary, the agile manifesto emphasizes people, interaction, working software, customer collaboration and change rather than processes, tools, contracts, and plans.
What’s Lagging in Traditional Methodologies?
Over the years many methodologies have been created to tackle the challenges of the ever-changing software development process, however all these methodologies share a few common elements. According to Martin Fowler’s article on “The New Methodology” (http://www.martinfowler.com/articles/newMethodology.html), he identifies the following common elements;
Benefits from Agile software development methods
There are numerous benefits that can be achieved from using agile development, which according to Forrester research are, improvements in time-to-benefits, overall quality and efficiency, team morale and relationship between IT and business staff, responsiveness to change.
Agile for Offshore Software Development
Much as been talked about in earlier sections with regards to challenges faced when carrying out offshore projects. This section focuses on how agile methodologies can be adopted to overcome those challenges. As mentioned before changes are the norm in businesses, therefore a process that’s flexible with changes and provides solutions to the above challenges, is a must if software development is to thrive in the current business world. Agile methodology is an answer to these issues and is a successful way of meeting expected business values.
We all know that it’s a massive challenge to work in an offshore context where the team is distributed, however using agile development, makes the project more manageable. The following sections illustrate how agile method was used in different aspects of the project life cycle.
Requirements analysis and documentation
Traditionally, the requirements gathering were done as one big effort, at the beginning of the project. This often takes a lot of time and is still considered incomplete at the end. In the early stages of the project, it is very often impossible to identify all the requirements. Trying to dig into details will only be a waste of time, since some requirements are not known at that stage.
Given the above problem it is best to do the least analysis and documentation as possible at the beginning. A scope document is sufficient at this point, this should describe all the things that the system should do, and should be written in a format that the customer can understand. Also it should only provide enough details to make a reasonably low risk estimate. This method not only saves a lot of time, but also provides a starting point for the project. Detail documentations for each function can be made as the project continues.
It is important that developers meet face to face with the client to understand and document each functional requirement very clearly. Either the client should make a visit to the vendor’s location or vice versa.
Functional documentation should be detailed enough to explain the functionality, but should avoid paragraphs and paragraphs of text. Paragraphs of text can lead to confusion and misunderstanding, instead the format shown in appendix ‘A’ which I used in the recent projects, worked really well for me. This method not only provides a nice template and reduces the time taken to write, but also makes life easier for the client to review.
Due to changing requirements, functional specifications will have to be changed often. When documentation has been written with paragraphs of text, it becomes a tedious job to keep it up-to-date, and therefore the ones prepared at the beginning of the project become mostly obsolete at the end of the project. Updating the documents finally ends up almost as a new project.
With a format such as that in appendix ‘A’, I found it very easy and less time consuming to keep them updated during the coding cycle itself. We were able to get the developers themselves to keep these documents updated, which usually would be tough. Hard core developers don’t like anything other than coding.
One of the other important section, that has to be included in the functional documentation is the user acceptance test plan. Having a test plan attached to your documentation provides the developer with a more sensible goal to make each test case to pass. This method is quite different from the traditional methods, but provides maximum productivity to take control of risks in managing offshore projects.
Apart from this, we also encouraged people to use video conferencing, phone, and on-line chats a lot. This not only reduces the problem with slang but also enhances team spirit among onshore and offshore team, as well as makes both teams see each others slang as a fun thing, and learn from it.
A project plan should exist at any given point in time. How detailed this plan would be, varies with the level of knowledge that we posses of the project. Most project plans change during the project cycle as we gain more understanding of the project. There are many tools out there to help you do project planning, but the most widely used one is the Microsoft Project. When you select a tool, make sure that your client too understands it.
The next step after selecting a tool would be to do the actual planning; which involves doing a task breakdown. Task breakdown should be done on a functional basis, where each task should have a meaningful output and should be testable by an end-user.
Tasks can be estimated using the three point estimation system. You can use the developers themselves to do this, since who else would be more qualified than those who will be directly involved in building the software. In order to do this estimation, I gather these 3 different figures for each task. The final estimate is calculated based on the following formula.
The above method provides valuable information on the amount of risk associated with the task. This is determined by the difference between the realistic and the pessimistic figures. The higher the difference - the greater the risk.
As the project moves along, it is important the project plan is kept up-to-date; therefore it is important that we capture the actual time spent. These figures can be easily obtained from the developers, by giving them a simple timesheet to fill on a daily basis. It is best if a project policy is made with regards to percentage completed, this should be communicated to the client as well. Telling a customer that a certain percentage, like 50%, is complete makes no sense for them.
Instead if a policy is made to denote that when a module is completed the percentage will be 60% (if its half complete then its 0%), and when it has been tested it will be 80% and when it’s accepted by the client it will be 100%. In order to be successful at this, the project should be broken down into small units as possible, but each unit should be testable and measurable by an end-user.
Managing deliveries is critical in any software development effort. Deliveries have a direct impact on expectations therefore how often releases are made, has to be determined very carefully. If the plan is to deliver once in every six months, then there is a very high risk that expectations will not align with what is delivered. Therefore the shorter the delivery period the better it is, but how short should it be, depends on your team, type of project and stakeholders.
Periods which are very short can cause stress for the team, overheads in release management and planning. For long term projects (such as one calendar year) one month periods are ideal. The selected period has to be used as fixed periods for delivery. This is referred to as time boxes, where delivery date or period is not changeable.
What can only be changed is the content or the scope. Scope defined for a time box has to be delivered fully completed at the end of each time box as agreed. So what is delivered at the end of each time box are modules which are testable and can be clearly measured with respect to progress. If the contents have to be altered in a particular time box, then it has to be notified and agreed among the concerned parties.
Contents, or scope, for a particular time box should be fully achievable and realistic, within the set time frame of a time box. No activities should be incomplete at the end of the time box. The whole idea behind this is to have a clearly measurable and testable unit.
If for any instance, a particular module cannot be completed in one time box and has to span through multiple time boxes, then this module will have to be broken down into clearly testable sub modules. These can fit into a time box and can be completed in full, by end of that time box. Based on this a project plan has to be made and agreed among the project stakeholders.
The thinking pattern behind project planning using the time boxed approach is slightly different to the traditional approach. In order to get the maximum efficiency, divide the activities of a project into the following three;
Each of the above levels of tasks are carried out on successive time boxes. A requirements analysis carried out on Time Box 1, will have its requirements coded, tested and integrated in Time Box 2, and delivered to the client for acceptance testing at the end of Time Box 2. The client can do the mini user acceptance in Time box 3. Therefore this approach not only solves the problem of getting on with development faster, but also provides the flexibility for changes to happen in, on-coming time boxes – see diagram below.
Integration is a real nightmare and a painful process even with a lot of care and dedication. Imagine several components being developed which have to be integrated almost at the end of the project. This would be a very difficult and time consuming process. On top of this, clients wouldn’t have a meaningful software to test, and would always be in the dark, with regards to what they are ultimately going to get.
Continuous integration is an ideal approach to overcome the above situation. Each module is developed and integrated to the main software, before releasing it for testing. So this type of integration enables clients to see all components working together. It also allows them to come up with feedback early rather than having to visualize how it would look later when integrated.
Transparency and Progress Monitoring
Stakeholders are always concerned about the progress of their projects, which makes project transparency a critical issue in managing offshore development.
Periodic progress reporting is necessary to keep the stakeholders aware of the project progress. Agile methods track progress by means of completed testable features as opposed to percentage of work completed. Percentage complete means components are neither testable nor tangible. This method of tracking prevents features from being under developed to meet time and budget constraints. Cutting scope usually means a surprise at the end when it is discovered that more work is needed to be done, when that solution is to be deployed.
The most meaningful way to represent progress is via a simple graph, based on actual work performed. Imagine showing a progress report with a graph as in the figure below to your client who is technically not competent in reading your technical projects plans? It would easily make sense by comparing the estimated and the actual curve. The graph below clearly shows that the project was on schedule at the end of the first time box, but later shows deviation from the estimated performance. The deviation seems to increase at the end of each time box. A graph such as the one below can tell a lot of stories regarding how the project progressed from beginning to end.
The above graph is based on earned value versus the time boxes, and is drawn for a project with four time boxes (each time box is one week). Earned value is an objective measurement of how much work has been really accomplished.
The following example illustrates how a graph like this is drawn. Assume a project with the following tasks and time boxes;
Budgeted cost of work performed (BCWP) is the actual amount of work completed at a given moment from the original scheduled work, and is calculated as follows;
BCWP = Estimate * Percentage Completed
Based on the above data the project progress will appear as follows;
BCWS – Budgeted cost of work scheduled.
Some of the other details that I normally include in a progress/status report are
The above is information that I normally include, however it will vary with each client’s expectations and needs.
Active Client participation
It is beneficial to get the user acceptance plan prepared along with the module specification (at the requirements analysis stage). In fact it’s even better if the client himself prepared it, since this communicates the requirements even more clearly to the development team.
Secondly at the end of each time box, the client should carefully test each deliverable against the user acceptance plan made by them, and provide feedback to the software vendor.
Document and Source Code Management
Proper document and source code repositories and version control systems are very important. In fact the tool you select for the above purpose should allow for transparency and distributed development.
There are many web based open source tools such as Trac and Bugzilla to help you achieve this. Web based tools (such as “Trac”, which is an open source Wiki), can be easily accessible by all parties irrespective of where they are located. When selecting a tool, careful attention has to be paid for the fact, that not all stakeholders in a project are technically competent. Ease of use is a critical factor when selecting a tool. Wikis are excellent tools to use in an offshore-distributed team environment, mainly because of their simplicity, ease of use, browser compatibility and simple to set up features. Some of the common features provided by most Wikis are
This article will be continued in part two of the white paper.
About the Author