Showing posts with label improvement. Show all posts
Showing posts with label improvement. Show all posts

Friday, July 20, 2012

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.

Sunday, April 3, 2011

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

Friday, March 4, 2011

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.