Skip to main content

my philosophy towards project management and a book...

    Good software project management minimalizes the time required to create, modify, and maintain the software while achieving acceptable runtime performance.
    This definition and the conclusion it leads to, are the most important things I keep in mind when considering project management. I follow some core management principles, and I have some techniques that are useful for the different projects that I work with. However I am willing to throw away even the management principles if they get in the way of reducing programmer time and, most importantly, solving real customer problems.
   The same is true of agile software project management. Ultimately, what matters is success, however you define it. The practices, principles, and values are merely guides along the way. Start by following the practices rigorously. Learn what the principles mean. Break the rules, experiment, see what works, and learn some more. Share your insights and passion, and learn even more.
    Over time, with discipline and success, even the principles will seem less important. When doing the right thing is instinct and intuition, finely honed by experience, it’s time to leave rules and principles behind. When you manage great projects for a valuable purpose and pass your wisdom on to the next generation of projects, you will have mastered the art of successful software project management.


What you read above is a slight modification of a few paragraphs from the book The Art of Agile Development. It summarizes my attitude towards Project Management/Software engineering. Thank you James Shore and Shane Warden for the above words.

Now here is the actual wordings.

  A good software design* minimalizes the time required to create, modify, and maintain the software while achieving acceptable runtime performance.
  This definition and the conclusion it leads to, are the most important things I keep in mind when considering a design*. I follow some core design* principles, and I have some techniques that are useful for the languages* I work with. However I am willing to throw away even the design* principles if they get in the way of reducing programmer time and, most importantly, solving real customer problems.
The Art of Agile Development   The same is true of agile software development*. Ultimately, what matters is success, however you define it. The practices, principles, and values are merely guides along the way. Start by following the practices rigorously. Learn what the principles mean. Break the rules, experiment, see what works, and learn some more. Share your insights and passion, and learn even more.
   Over time, with discipline and success, even the principles will seem less important. When doing the right thing is instinct and intuition, finely honed by experience, it’s time to leave rules and principles behind. When you produce* great software* for a valuable purpose and pass your wisdom on to the next generation of projects, you will have mastered the art of successful software development*.

If you are a developer or a manager, do yourself a service by getting a copy of this book and of course, reading it :) I have no doubt that you will definitely learn a lot, and come back to this book time and again. I sure will...

* words i changed in the original paragraph.

Comments

Popular posts from this blog

Kano Model of Customer Satisfaction - Notes to Self

Note: What follows is the notes taken from my study of Kano's model of Customer Satisfaction. I came across this model when i wanted to know if there was a structured approach that would help me prioritize features for software product development. 

To evaluate a product or service, following parameters are very important

The value provided - this helps attract customersThe Quality offered - This earns customer respectProduct or Service innovation - This helps differentiate from competition
But these are not perceived directly, but indirectly through the product and it's features. Kano's model help to group product features into 3 categories ( 6 categories, but only 3 are important) and there by makes it feasible to deliver value at a promised quality while offering innovation. 

The 3 important feature categories are 
Basic featuresLinear featuresExciters or DelightersBasic features are that must be present in the product to be successful. They are also referred to as must have…

Knowns, Unknowns and Project Management...

This article is a draft of a paper i started to write in september 2007 and left it where you see it today.  The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome...
Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project.
All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use.
But the problem is that people usually look at these factors in black and white. This may be ac…

Aggressive Schedules - Few thoughts...

During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.

After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following.
Project ended up delayed by more than 100% Project got cancelled Project got de-scopedProject has a high cost of maintenance.  Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we …