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.

Trends in software process development

My attempt to describe the trends in software process development. Please view and comment. The six trends are

1) Agile
2) Technical debt
3) Reuse
4) Lean/Six Sigma
5) Social Management
6) Managed services

Part 1 and Part 2

        

The 3 types of process

We are all (all too) familiar with the ISO standards, CMMI levels and so on. All of these prescribe excellent processes and the benefits of which we are all realizing. At the same time, there are projects and organization that feel that some of the processes are not optimal for them. Maybe its an overhead? True - there is a discipline called Tailoring, but it is also one of the least understood processes from CMMI..after QPM that is!

Many organizations struggle to implement CMMI. After spending thousands of dollars in planning, assessment (and celebrating L5 with a party and gifts), within a few months, they are back to where they started. The biggest reason for this is the "ALL for ALL" approach. All processes for all projects. How do we change this and what can be a model to achieve this?

There are only 2 primary purpose to processes. One is Risk mitigation and Second is Improvements. We will call risk mitigation processes as "Safety" and one that gives improvements as "Premium". To make the decision making simple for us, we will add a third category - "Foundation". The purpose of this grouping is described below:

How does this categorization help implementation and tailoring? Will this be useful to realize full value of processes? We will see in next blog.

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!

Men in blue and Leadership

It is very difficult to associate Indian cricket team and Leadership. Over the years, it has been individualistic performances that have helped India win most matches. Even when India had great captains like Gavaskar, Kapil, Azhar, Ganguly etc, the individuals soared above the team. Team effort, coordination, consistency was not in the menu. That is, till recently. At this juncture, when India is the World champion, let us look at some of the leadership lessons from Indian cricket team

Leader that is Dhoni 

The biggest influence as a leader has been undoubtedly Dhoni. Stepping in as captain of a cricket team which had a billion followers is not easy. This he did at the age of 26. Dhoni showed that as a leader you have got to believe in yourself and your team. You have to support the team in its ups and downs. You have got to take risks. I would rate these as the brilliant decisions he took in this world cup

- At the start of the world cup, no body would have imagined that Yuvraj will the 2nd best bowler for India in this world cup. Dhoni’s had the faith in Yuvraj and it paid off. Another calculated risk that Dhoni took is bowling Ashwin in the beginning against Australia. Both these paid off. And I don’t think Dhoni would have been too worried if it did not pay off. After all, a few decisions like Nehra in that last over against SA, as well as playing Sree may not have worked well. But as a leader,Dhoni showed courage and belief in his team and believed that he was doing the right thing.

- Batting changes showed another key aspect of Dhoni as a leader. Always on the move and thinking. When Yusuf was not at this best in death overs, he had to see how best the support can be provided at the down. In spite of Raina being in not so good form (he had scored only 1 fifty in his last 24 ODIs), he took the risk to place Raina in the eleven. And in the final, he himself decided to come at number 5. As Jadeja was to state later, it is very rare that Dhoni would get out early if he decides to promote himself. A true trait in a leader! Leading the way from the front

*********************************************************************************************

Captain cool

Have you seen Dhoni loose his cool on the field? Have you seen him shout at his team on field? At the same time, if somebody makes a mistake, he is quick to see if any change is needed. Whether it is field placement or changing the bowler etc. A leader respects his team. He also gives them a second chance. In fact, even I was a little amused when Sree came to bowl a third spell yesterday. A leader does not react in the heat of situation. Leader always shows self control

*********************************************************************************************

Bringing team work is leadership

Not everyone can be a leader. We have seen that some of the greatest players like a Tendulkar or Muthiah Muralidharan were not Captain material. Still, this world cup final will be remembered for these 2 players as much as for others. 2 key lessons here:

- Within a team, there will people who perform well and they need to continue to do so. Being the captain is not the goal always.

- As a captain Dhoni brought out the best in everyone. It is important to recognize that there might be people who perform better than the leader. A leader has to perform well, not everyone who performs well is a leader

Team work is leadership. We had 3 different people bagging man of match awards in the 3 knock out games. We had almost every one in batting order fire in this world cup and almost all bowlers performing decently. That is team work and that is the true output of good leadership!

*********************************************************************************************

This world cup will be remembered for many years for many reasons - India winning it after a long time, Tendulkar’s last world cup (Well, surely :-)), Yuvraj’s man of series etc..but it will be also remembered for Dhoni’s leadership.

*********************************************************************************************

Congratulations to Men in Blue and all the best! Bleed Blue!!!

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 . . .