7 habits of highly effective Projects (& Project Managers!)

I thought stealing a title from a legend is a fitting tribute to the great man Stephen R. Covey who passed away recently. This book, written 22 years ago was a trend setter in self-help books. May he RIP.

When we look at current challenges in software, many times, we have an excuse. Software development is a relatively new field. It is less than 30 years old, compared to manufacturing which is more than 100 years old. Hence maturity of s/w development is less. But the point we are missing is that in these 30 years, we continue to grapple with same issues..Looks like change has been very slow.

In this article written some time ago, the author lists in a simple manner, 5 goals for a PM. Considering that this is a tall goal, probably 1 more can be added.

Goal # 6: When one or more of the above 5 goal is not met, find the scape goat!

I mentioned that in 30 years, core problems in software development has remained largely unchanged. These are:

a) Poor turn around times / not meeting time to market goals

b) Heavy budget over runs / poor productivity

c) Cost escalations after production releases due to defects, missed requirements

d) Increased maintenance costs etc

Just do a quick check of how many of these your client has and no surprises if they have atleast 2 of them.

So, what is the magic formula to prevent these? If not a magic formula, what are the “habits” that can reduce these? I give below the 7 habits which I think are important. These habits may be the direct responsibility of PM or in some cases PM may need to facilitate it. My intent is to provoke a discussion on this. So I would appreciate if you can comment and ask your friends to comment based on their experience. Maybe more habits from your experience will make this story richer. Hopefully, we can bring out a dossier to help current and future projects

Habit # 1: Visualizing and demonstrating requirements:

A good requirements is half the work done. Seldom do we find projects not meeting their goals when requirements are discussed, proactively elicited, demonstrated using prototypes and visualized. A good requirements stability does wonders. It is also proven using empirical research that a higher effort spent for requirements positively impacts productivity. Read that Insead study here

Habit # 2: Focus on structural quality during Design and Development:

When civil engineers build small or big buildings, a lot of effort goes in designing the foundation needed, the size of pillars and beams, the tensile strength of iron bars used etc. All this is done so that the construction is stable and will withstand the fury of nature. All this is true for applications. 1 more thing that is important in software apps is that all software apps changes during its life. Maintainability is key word. We all worry – more or less – about NFRs – performance, security, maintainability, etc. But do we worry about them during design and development ..or..do we worry about them during testing? As Codenizant has proved, good structural quality in development can greatly improve productivity

Habit # 3: Use Leading indicators:

Most of us are familiar with metrics. But how many us use it to make a decision during a project? Define a simple set of 6-8 leading indicators that work like a monitoring system in an emergency room. It may be simpler than you imagine 

Habit # 4: Plan less testing:

Testing is never the first solution to build quality. Testing is done to remove defects. Point is, why defects are there in first place? Yes..testing is like an insurance and you can’t eliminate it completely.  But there are numerous ways to reduce testing. Even if nothing works, just reduce testing and tell development team: “Look, we don’t have budget for testing. So please make less defects”.  You would be surprised..but it works

Habit # 5: Collaborate and Collaborate

Sometime back, I asked a few friends, excellent PMs, to write a case study about their successful projects. There was a common theme in the different case studies. All mentioned that collaboration and communication within their team members was instrumental. Do all of your team members share the same goal? Does everyone understand why we are doing this project? 

Habit # 6: Think of all reasons why your project will fail

…and plan to mitigate those risks. Of all project management processes, I believe Risk Management is most important, because this will ask you for a mitigation plan if you don’t follow others 

and finally…

Habit # 7: Own the project

We have different type of projects. Some where we do everything from Requirements till testing, some where we do only Development and testing. There will be many other combinations as well. Some may be Fixed bid, some staff aug. Some may have client PM. Whatever be the scenario, own the project. Its your baby. Make it grow.

Quality Wishes - the seven notes of quality

How can Software quality professionals change the face of quality and software quality assurance in 2011? Inspired by ASQ initiative of Quality goals for 1022, here is my list of 7 wishes for software quality and hope that we can work towards these!

Wish # 1: Audits do not unearth mistakes. Only improvements - This calls for a mindset change in audits. Correcting mistakes do lead to improvement, but would it not be better to shift the focus and look for improvements rather than mistakes?

Wish # 2: We don’t make the same mistake twice - There is an age old saying, “Make only new mistakes”. In the context of an organization, we can safely assume that only the mistake first made anywhere within the organization counts as the new one. Do we believe that the mistakes we make are always new? Or do we try to find out mistakes made earlier and not repeat them…

Wish # 3: We reach a CoQ of 25% - We are happy to test less and save money for our clients. 

Wish # 4: A project award is instituted for the project that failed badly after trying – Should we not give reward for taking risks and creating learning’s?

Wish # 5: A working code is not the only goal - Meeting all functional requirements is probably less than 25% in a project. Making the application live up to performance requirements, maintainability (less time to maintain), usability (easy to use), secure will have to be of utmost importance.

Wish # 6: Project data is treated like money. We don’t waste it - There is no compromise made in project data – be it effort, defects, size, schedule, Requirements etc.. Will anyone accept 1 dollar as 90 cents?

Wish # 7: Customers don’t set SLAs. We set them – Performance standards are set by projects and we constantly beat them. No more waiting for some else to tell us what is quality!

My goal for 2011 would be to start working on realizing these goals in my work. Hopefully I can share updates a couple of months down the line!

Why and Why not - Why metrics gets a step motherly treatment

While software metrics have been around for many years, accurately understanding what the metric means and using it effectively in a project has been an issue.

The Challenges
1) Software metrics deal with variable measurements. Effort, Size are variables and hence have high degree of uncertainty in their measurement. In addition the measures, including defects, are captured by individuals.
2) Many metrics are measurable only at the end of project - like productivity, Review effectiveness etc. This results in project teams not giving importance to capturing data during the course of project
3) Lack of integrated tools to capture and report data
4) Metrics are seen more as value adds rather than hygiene. Even today, many of projects and clients are unaware about the power of data, benchmarking and decision making using project performance data
5) Software project inefficiencies (like high CoQ, defect densities) have not grown to a state where they are a problem. We are still content to live without knowledge of the inefficiencies. In other words, the power of improving project performance by understanding current performance is not realized by many


In order to mitigate the challenges, all that is needed is to follow a simple series of steps

1) Understand the project, client and organization objectiveness and define your project goals. 
For example, one of the client goals will be that the end users have to be really satisfied and have to spend less time testing the software. This will translate to a goal on Delivered defect density
2) From your project goals, define the measures you want to track in your project and have an appropriate tracking tool
Without a proper system to track data, it will be "Junk in Junk out"
3) Ensure that all your team members understand why a certain metric is tracked
4) Ensure that data is tracked frequently and logged so that integrity and quality of data is good
5) Monitor project performance regularly - atleast once a month
6) Compare the performance against goals and benchmarks
The benefits of a good metrics system is more when you are able to take decisions at regular intervals


For your information, a basic list of all metrics and how they are relevant is attached here


Please post your views, feedback and experiences. If you need any further infromation on these topics, please comment and one of us will respond.

ABCD of Metrics

Would you decide to buy a car without knowing its mileage, maximum speed, cost, maintenance cost (service), etc.? And after buying, will you not keep track of the expenses you incur on the car to judge whether you got value for money?

A software project in many respects is similar. It is like car. When a client buys a software, the purpose , design (model of car), performance (speed of car), cost, total cost of ownership (service for a car, fuel efficiency) etc all need to be considered. Ofcourse, this is all in addition to the fundamental need - a defect free product. Similarly for a manufacturer of software there has to be considerations around aspects like productivity.

Does all of above make it sound complex..? Lets decode it

Before even we discuss software metrics, lets talk about measurements in software. There are, at first level, just 4 basic measurements.

1) Effort

2) Defects

3) Size

4) Schedule

These 4 measurements all have a single unit associated with it. Like Person hours for effort or a Function Point for size. All are independant units of measurement. It sometimes amazes me that collecting and tracking these 4 in a projects is considered a huge task!!

It is possible to compute innumerous Metrics from these 4 measures. Many efficiency and effectiveness related measurements are possible using these 4 measures. There have been additional basic measures that have been used, but that does not add the complexity of the efficiency and effectiveness, but it shows that the industry is maturing. 100 years back, doctors never knew that there is a relationship between blood pressure and heart attack. Now there is a relationship that has been established. Similarly software metrics have developed. Today, we are researching about relationships bewteen Coupling between Objects, Cyclomatic complexity etc on defect rate, productivity and cost of maintenance etc. Software metrics are maturing..

More about metrics soon . . .