Posted by: ahmedashfaque | September 23, 2014

How to deal with difficult people on projects – part 2

Continuing this series from last post on dealing with difficult people on projects, here is another post.

Once when I was working with a company in Toronto, Canada, I had a boss who was very demanding. Most of the people in the office used to do their work with zeal. But i saw one guy who was always free. He never used to have any assignments. Once I asked my boss why this guy is always free. he told me that if he would give him any assignment then he will have to sit with him. And so he was never giving him any assignments. and that is how this guy was always free. he never had to work on any assignments at all. I was puzzled. I asked my boss why so? He told me that this guy needs to be told each and every step of the project task. For this the boss himself would have to sit with this guy. So my boss would never assign any project task to this guy.

So how this guy survived? Why the company would not fire him? It was because the guy happened to be from the same place in India from where my boss belonged. So boss would never give any bad feedback about this guy to the company.

This is very true in many places. Many people survive on the job because of this kind of setting. The project work is done by other people and these people just survive without doing anything.

This is indeed a very bad practice. But in practice many bosses do it to a hilt. They know who is working and sincere and assign all the project task to these kind of people and spare some guys who are actually a headache if they are assigned work.

How to make sure that this kind of practice does not happen on projects? It is difficult as long as there are this kind of bosses around. One good measure could be making the project managers accountable for every dollar spent on the project. Project performance in terms of dollars spent against work output should be directly linked to pay of the project manager. In that case, the project manager will know that any dollar going in the drain will impact his salary. Only then they may desist from such kind of behavior.

Posted by: ahmedashfaque | September 22, 2014

How to deal with difficult people on projects – part 1

Software projects are all about managing people. It is people who do all the work on software projects and it is where everything matters. Unfortunately on many projects there are people who are difficult to manage. So how to deal with such people?

On a project, I had one software tester who was extremely soft spoken and was very nice. If you talk to him, you will always get a very good impression about the guy. But at the same time, he was extremely smart to avoid any work. Any project work assigned to him would definitely land in the list of delayed tasks. At the same time, he had convincing answers for all those delays. Initially I accepted those explanations. Then as this happened all the time, I started investigating his work.

I found that he was smart on finding holes on specifications or lack of details about the task to be performed. His modus operandi is mentioned here.

He would accept the task once a task was assigned to him. He will immediately start working on finding the holes in the specifications. Once this is done then he will while away his time in talking to his friends over his mobile or going out of office and doing whatever he was interested in. He also knew pretty well that the project manager has too many people and problems to deal with and so will not bother to ask for task progress for some time. And this time can be used for seeking pleasure and whiling away time.

Now everybody knows that finding or providing all the specifications for a task is impossible. It is also a fact that taking task progress report from everyone on the project can not be done very frequently. So for example when i would ask for a task progress report from this guy after 2 days, he always used to have immediate excuses. This way several days of project work used to get lost.

After my investigation & analysis i called him in my office one day. This time i gave him a project task and asked him to find out every piece of information he needed to get this task completed within 2 hours. He accepted the task and left. He came back after 2 hours and gave me the list of holes in the specifications. I sat with him and discussed every hole one by one. Finally I told him that all specifications for any project task is impossible to furnish and the team members find out the alternatives or assumptions from their experience. For example, he was supposed to write test cases based on requirement document. The requirement document itself may not be available sometimes. But still test cases can be written based on some other documents like mock up documents, pilot presentation etc. All other project team members who have other project tasks may not find time to furnish each and every document. It is perfectly acceptable if they have provided some alternatives instead of the exact deliverable from their completed tasks.

from then onward, this guy also started delivering good on the project. He now knew that I know his methods and I will not tolerate any delays.

On most projects, this is a real problem. The project manager can not monitor and observe everything which is going on and some project team members take advantage of this fact. But a smart project manager should be able to find out what is going wrong and find out solutions.

There are many blind spots on a project and the project manager should be able to spot and find out those blind spots and work to remove them.


Posted by: ahmedashfaque | September 21, 2014

Lessons learnt: Testing complex business logic

Once I was involved in testing a business component which was extremely complex. This component was supposed to make a business transaction under varying business scenarios. Based on applicable hard and soft constraints, it was supposed to return possible business transactions and the end user was supposed to pick one of the transaction and committ it. It had some 20 main constraints. These constraints were further divided into many sub constraints. In total there were some 500 constraints. The problem was further exascerbated by the fact that some of these constraints were hard constraints whereas others were soft constraints.

The hard constraints could never be overridden but the soft constraints could be overridden. That meant, if a hard constraint is applicable in a business scenario then transaction could not take place. In such cases, a test case will fail and no further testing is required for that business scenario. However if in a business scenario, a hard constraint as well as a soft constraint is applicable at the same time then the soft constraint will be overridden and only the hard constraint will be applicable. Testing this component was a daunting task indeed because for any transaction, tester had to check for all these constraints (numbering 500) in one test case!

Initially no tester was ready to take this challenge. Then a brain storming session was organized consisting of a team of line managers, business analysts and testers. All of these people were obviously not at one place so the session took place in the cyber space, over a virtual conference call. After breaking our heads for 3 hours, over 3 sessions of one hour each, a strategy was evolved. It was decided to make a decision grid which will guide as to when a transaction will take place or not, based on the test data input as well as prevailing business scenario for that test case. Each prevailing business scenario was identified later and test cases created. In each business scenario, which constraints were applicable and which were not was clearly indentified. Similarly whenever a soft constraint was applicable, it was made sure if any hard constraint was overriding it or not.

Finally test data was created on the testing system and testing got started. Later most of the test cases were ported to test the production instance as well.

Sometimes brain storming sessions work!

Posted by: ahmedashfaque | September 20, 2014

How project lifecycle and software development lifecycle are linked?

Project phases like initiation, execution and closure are well defined. They have definite start dates, end dates, resource requirements etc. They also have a sequential relationship with one another. So project execution follows project initiation. Similarly project closure follows project execution and not vice versa.

When the project is for software development or software maintenance then software lifecycle phases have to be fit inside the project phases. How it can be done?

Software development phases (requirement gathering, design, construction, testing, release) may or may not have this sequential relationship with each other depending on the software lifecycle methodology chosen. But definitely all of these software lifecycle phases fall within the time span which corresponds to project execution. So in a way project execution phase engulfs all of the software lifecycle phases.

Software development planning can be done during project initiation phase.

This way, software lifecycle phases and project lifecycle phases are linked to each other.

Posted by: ahmedashfaque | September 19, 2014

Difference between project lifecycle and software lifecycle

Many people who are absolute laymen do not know anything about project management let alone know what is software lifecycle. But even people who are working in the software industry for sometime; get confused between project lifecycle and software lifecycle. Let us get it cleared.

Project management is the process which helps in getting any project planned, initiated, executed and finally finished. These process steps can be called project phases. Each and every project goes through these phases. So lifecycle for any project can be considered to be consisting of these phases.

Software development is also done through many steps. First a software product or application is conceived. Then all the features and facilities which are to be included in the software product is finalised through user interaction. This is known as requirement gathering. Based on the requirments, a software design is made. Software coding is then done using the software design. After coding, software product gets completed. This product is then tested. Once software product is found to be good enough for use then it is released to the user community. Later when enhancement of features or user reported defects are to be fixed then a maintenance plan is made and maintenance is done.

All these process steps which are used for developing or maintaining any software product or application can be considered as phases. Software lifecycle basically consists of these phases.

Here is the link from where you can download first chapter of my book “Software project management – A Process Driven Approach“. The book is not only discusses software project management but it discusses software engineering processes as well.

I hope you will like it. Feedbacks are most welcome. Software Testing

Software testing is very important area because most of critical bugs should be trapped here. Otherwise fixing those bugs in maintenance phase becomes very costly. Software testing is undertaken as a separate project on many software development projects as it provides a lot of additional value. In such cases, it is known as independent verification and validation (IV&V). IV&V helps in trapping defects at all phases and in all work products during the entire development lifecycle. These defects are subsequently removed. Making a separate project for testing thus helps in increasing reliability of the software product.

Some of the challenges for software testing include too many defects in the software application which increases load on software testers, lack of test strategy, lack of test planning etc.

Software testing has been gaining importance over the years. Customers now expect a lot more better quality from their software products than it was the case a few decades back.

Software testing includes unit testing, integration testing, system testing, user acceptance testing, performance testing, usability testing etc. IV&V includes requirement specification review, design inspection, construction inspection, integration inspection etc. So scope of testing has increased on software projects manifold after advent of IV&V.

Developed software contains many bugs. These bugs are introduced in the developed software due to faults in requirements, software design and software coding. Purpose of software testing is to find these bugs so that they can be removed. This kind of software testing is known as functional testing. Functional testing is of 2 types viz. white box testing and black box testing. When developers check their own code for testing logic of the conditional statements or checking formatting of data etc., then this kind of white box testing is known as unit testing. In integration testing developers test whether data is passing correctly between functions. So most of white box testing; revolves around testing at function level.

When it comes to testing at system level, black box testing techniques are used. Black box testing is also used for user acceptance testing. In black box testing; requirements and design documents are referred to assess whether the built system adheres to what was required by the customer.

Apart from the functional aspects; the built system is also to be checked for many other aspects. For instance; whether the built system can withstand load of transaction requests made by users on the server on which the application is installed. Then usability, system integration many other kinds of aspects are to be tested to verify if the system is working as per these expectations.

The software system can contain a large number of bugs. It will be very difficult to detect all of the bugs. Even if you employ a large testing team, it may take considerable amount of time to detect a fraction of all bugs. This kind of exercise will not be of much use. If we are testing a software product then the marketing team can not wait for long as they need to put the product in the market within a specified time frame. If we are testing a software application specifically built for an organization then that organization can not wait for long to get to use the application. Moreover the cost of such a large testing effort will be huge. This kind of testing activity is simply not acceptable.

A better approach is to have an effective testing. There will be a time limit under which all testing activities have to be performed. There will also be a cut off quality level which is acceptable to the customers. So a compromise between quality level and time to test the application has to be made. For example; we can have a schedule of 15 days to test the application and acceptable quality level of 100 critical bugs to be escaped after the system goes live.

For all kinds of testing to be effective, a comprehensive framework is needed. As has been seen stated previously; the user acceptance testing needs requirement document and a good understanding of what exactly customer needs in the system. The system testing is based on system design document. The integration and unit tests are also based on design document but they are done at much lower levels. System testing is done at system level where as unit and integration testing is done at function level.

Testing should also be prioritized based on needs of the project. For instance, of all the requirements some requirements are of high priority and some others are not. Definitely high priority requirements should be tested first so that they are covered even if time does not permit to do further testing. In such cases, low priority requirements may not get tested but the impact on the project in such instances will be much lower compared to cases when high priority requirements could not get tested due to time constraints.

Similarly when it comes to system testing; the testing team should have a very good idea about the design and architecture of the system. Only then they can do testing effectively.

These things can happen only when the testing team gets involved early in development lifecycle.

Here is an excerpt from Chapter 7 of my book “Software project management: A process driven approach”

Let us see an example to observe how EVM works.

Suppose we have project where schedule of the project is planned as 100 days. The budget for the project is allocated at $100,000. After elapse of 60 days, project measurements are taken. It was found that budget of $50,000 was consumed up to this point in the project. Suppose at this stage, 40 days worth of project is actually complete. But from the planned schedule, it should have been 50 days worth of project completed. So how the project is progressing?

In the identify deviations section, we have seen that in a simple scenario where project schedule and project budget are allocated linearly (project budget and schedule are consumed linearly in proportion to total budget and schedule). That means the project progress should be linear. Alas! It does not happen that way. There is no linear progression of the project in real life. It is because any project has many tasks and each of these tasks has its own volume of work to be performed at different rates over period of times. For instance, a software design task may be completed over a period of say 20 days. If the work was performed linearly then each day, percentage of work is to be completed 5% so that in 20 days 100% of the work will be completed. In reality however on some days the planned work may be 3%, 5%, 6% or could be just any other value. It all depends on availability of resources on particular days and dependency of a task on any other task. Similarly, the budget consumption is not linear. Some tasks are cheaper to be performed than some other tasks. So in a unit of time, some tasks can be performed with more volume than some other task for the same consumption of budget. So far we have discussed the non-linear behavior for planned budget and schedule. Likewise, the actual budget and schedule consumption will also be non-linear. Once we understand the non-linear relation between % completion of any task vis-à-vis completion of total task for both planned and actual progress then it will be easy to understand the concept of EVM.

Coming back to our example, we have actual cost (AC) as $50,000 and planned value (PV) as $55,000 (corresponding to the planned days of work performed up to this point). The project manager has also been tracking the earned value for the project on a weekly basis. On this basis, he has been plotting the earned value for the project as it progresses. From this figure, he has an earned value (EV) of $45,000.

Now let us do some mathematics with the figures we have.
Schedule Variance (SV) = 45000 – 55000 = – $10000
Cost Variance (CV) = 45000 -50000 = – $5000
Cost Performance Indicator (CPI) = 45000/50000 = 0.9
Schedule Performance Indicator (SPI) = 45000/55000 = 0.82

For both CPI and SPI the ideal values are 1. In the case when CPI is 1 then it means that the project budget is being consumed as per project plan. Similarly if SPI is 1 then the project schedule is progressing as per project plan. In our example, we can see that at the point of measurement, the project is lagging behind both in schedule and in budget consumption (as both are less than 1). The project manager can do well to find out why the project is lagging behind and how the project can be taken back on the right track.

Continuing our discussion from part 1 of this article, let us discuss the concept of mass servicing of projects.

To understand mass servicing of projects better let us first discuss the concept of mass manufacturing. Mass manufacturing of products is a well known and understood phenomenon. In industries where continuous production of same kinds of products is possible, a strategy is adopted to reduce production costs by increasing productivity of resources including that of machines and men working in the production department. This increase in productivity is achieved by reducing set up time of machines, idle time of machines and reducing scrap generation of products. This increase in productivity in turn reduces production costs.

Mass manufacturing concept is tied with the idea of producing large number of same product through a production line and keeping unproductive activities like machine downtime, set up time, idle time etc. to the barest minimum. This results in setting up of different production lines for different types of products and setting up of center of excellence. This in turn ensures that same kinds of activities related to production are grouped together, resulting in efficiency of operations and improving productivity.

This same concept of mass manufacturing can be applied to services. Same kinds of activities can be grouped so that efficiency can be achieved in service operations and productivity can be improved. In software industry, where people are the only asset in producing software products (there are no machines used), efficiency can be achieved if similar project activities and software production activities can be grouped together across different projects. Then these grouped activities can be performed through mechanisms like center of excellence. For instance, we can have center of excellence for software testing activities, software design activities etc. this means that we can have a pool of software architects who will architect software products across many projects. We can have similar pool of software professionals doing group activities.

This kind of set up indeed results in manifold increase in productivity and achieves improved efficiency. The requirement for this scenario is that the company which has created these center of excellence should have a large number of similar projects.

In such a scenario, what could be the impact on software professionals? the most profound impact is that it reduces creativity on the part of the software professionals. Software development after all is a very creative activity. Reduction in creativity will result in developing innovative software products. This may also result in dissatisfaction among software professionals.

But not all software products need to be innovative. In fact, a large number of software development projects these days do not require a high level of innovation. On those projects these concepts of mass servicing can be easily applied. Reduction in costs of software development will result in higher rate of adoption of software products by customers. Which will result in higher growth and revenues for the industry. This will result in more employment opportunities for software professionals. More employment opportunities will also result in reduction of bench time for software professionals which in turn will ensure a better pay for them.

Projects after all have a predefined life. They born, grow and finally die when project completes. Software projects are no different. In fact most of the software industry is based on project work. Software professionals are recruited to work on a project when a project is going to start. When project ends, software professionals working on that project need to pack their bags and look for another project to work on. If their company has any other project for them then it is fine or else they have to sit on the bench till they are selected for a new project. If they are contractors or self employed then they become unemployed till a new project comes along and they are hired to work on that project. This results in semi-employment to temporary unemployment for the software professionals.

This kind of unsteady work environment is detrimental to software professionals. Contrary to other industries where people have steady jobs, software professionals face many ups and downs in life because of the unsteady work environment in which they work. What can be done to improve upon this situation?

This kind of variable nature of the software industry not only poses problems for software professionals but it also impacts software companies severely. they end up having variable revenues and uncertain future. So many of these software companies have come up with certain strategies to minimize vagaries caused by this nature of the industry. This in turn also helps software professionals who are working as employees in those companies in many ways. Let us discuss these strategies and how it impacts the software professionals.

Variable Pay

Most of software companies have a pay package for its employees which has a fixed component and a variable component. When any employee is working on a project then he/she also is eligible for variable component as well. When he/she is not working on any project and in fact is sitting on bench then he/she does not get this variable component. This way, the company minimizes its risk. The down side of this strategy is that employees get less salary when they are sitting on bench. The plus side is that employees at least are getting a salary even when they do not have any project work to do.

Large number of projects

Small software companies have a limited number of projects. When a project finishes, company faces a problem in shifting employees to another project as getting new projects takes time. So employees working in smaller companies have larger bench time compared to bigger companies where a large number of projects are available to be worked on. Larger companies have a better chance of pooling employees and projects together and keeping bench time to the minimum. So employees working for larger companies have an advantage as they have more chances of getting most of the variable pay on top of their fixed pay.

In the next part of the article we will discuss a strategy which I like to call “mass servicing of projects” akin to “mass manufacturing”.

Older Posts »



Get every new post delivered to your Inbox.

Join 38,451 other followers