….on this blog at least. I started this off with the intention of writing my experiences in Project and Program Management. And as the readers of the blogs would have noticed, most of my postings are related to Spirituality and Meditation. I deliberately stopped posting anything relating to PM since I did not want any conflicts with my current job. So there it is the demise of PM on this blog at least. The tag has changed.
I have been a passionate reader and implementor of methodologies right from James Martin’s Information Engineering to Tom De Marco’ SSAD to James Rumbaugh’ OMT to RUP. I also made a modest contribution to Accenture’s ADS during my tenure with them.
When I first came across FDD a few years back, I really liked it for the simplicity that it provided to the management of the entire development process. I tried it very successfully on a large project that I was working on. Today it gives me great pleasure to see FDD implementation being incorporated as a partner solution in Microsoft’ Visual Studio Team System.
My Congratulations to Vincent and team who made this happen.
[From ASK overview]NASA Academy of Program and Project Leadership (APPL) publishes a magazine called ASK, which is available for online viewing. The ASK Magazine grew out of APPL’s Knowledge Sharing Initiative. The stories that appear in ASK
are written by the ‘best of the best’ project managers, primarily from
NASA, but also from other government agencies and industry. These
stories contain genuine nuggets of knowledge and wisdom that are
transferable across projects. Who better than a project manager to help
another project manager address a critical issue on a project? Big
projects, small projects — they’re all here in ASK.
Bill Townsend, Deputy Director at NASA’s Goddard Flight Center, shares his experiences in the latest issue of ASK:
When I read the following sentence:
"When minority opinion isn’t valued, people are afraid to speak up, and
they end up giving in to conformance pressure even though they know
there’s a problem. So I wanted to make sure that I took the time to
hear the dissenting opinion."
it stuck me that I too have been guilty of not soliciting and seeking out opinions from the minority. Should remember this.
Talk about
offshoring … Roger Green and David Cook, two San
Diego tech
execs are taking the term literally. The two plan to
purchase a secondhand cruise ship, populate it with 600 of the brightest
engineers they can find, and then park them all in international waters three
miles off the coast of El
Segundo, thereby avoiding
H-1B visa hassles while still exploiting offshore labor costs. Oh, and the
engineers? They’ll be given all the amenities a cruise ship has to offer:
private rooms with baths, meal service, laundry service, housekeeping and access
to on-board leisure-time activities. "Engineers can be kind of quirky in some
ways, but they can be really productive if you give them the right setting," Green
told SourcingMag.com. "We think we’re going to be putting them in the
perfect setting. Very few distractions. They’ll be with
similarly motivated people who are really interested in advancing and doing this
engineering work. It’ll be this perfect place for getting engineers to
work."
V.P. Kochikar, KM Head, Education &
Research Department, Infosys Technologies, says "KM helps us stay on
top of new software projects, emerging technologies and customer
satisfaction" I take every media interview especially when it comes from an IT organization, with a large grain of salt, but some of the things Kochikar talks in this interview are fascinating to know especially the one relating to incentivising the KM process.
The latest issue of The Rational Edge has an interesting article on Software Management.
Managing
software projects successfully has proven to be very failure prone when
using the traditional engineering management discipline. Comparing the
challenge of software management to that of producing a major motion
picture exposes some interesting perspectives. Both management problems
are concerned with developing a complex piece of integrated
intellectual property with constraints that are predominantly economic.
This article introduces some comparisons between managing a software
production and managing a movie production, then elaborates four
software management practices observed from successful projects. The
overall recommendation is to use a steering leadership style rather than the detailed plan-and-track leadership style encouraged by conventional wisdom.
Written by Walker Royce, author of the popular book Software Project Management, the article brings out a great point between precision and accuracy - terms which I first encountered in the software world when I read Steve McConnell’s Code Complete :
In a successful software project, each phase of development produces
an increased level of understanding in the evolving plans,
specifications, and completed solution, because each phase furthers a
sequence of executable capabilities and the team’s knowledge of
competing objectives. At any point in the life cycle, the precision of
the subordinate artifacts should be in balance with this understanding,
at compatible levels of detail and reasonably traceable to each other.The
difference between precision and accuracy (in the context of software
management) is not as trivial as it may seem. Software management is
full of gray areas, situation dependencies, and ambiguous tradeoffs.
Understanding the difference between precision and accuracy is a
fundamental skill of good software managers, who must accurately
forecast estimates, risks, and the effects of change. Unjustified
precision — in requirements or plans — has proven to be a substantial
yet subtle recurring obstacle to success. Most of the time, early
precision is just plain dishonest and serves to provide a facade for
more progress or more quality than actually exists. Unfortunately, many
sponsors and stakeholders demand this early precision and detail
because it gives them (false) comfort with respect to progress achieved.
One
of the most common failure patterns I have observed in the software
industry is developing a five-digits-of-precision specification when
the stakeholders have only a one-digit-of-precision understanding of
the problem, solution, or plan. A prolonged effort to build a precise
requirements understanding or a detailed plan only delays a more
thorough understanding of the architecturally significant issues. How
many frighteningly thick requirements documents or micromanaged
inch-stone plans have you worked on, perfected, and painstakingly
reviewed, only to totally overhaul them months later after the project
achieved a meaningful milestone of demonstrable capability that
accelerated stakeholder understanding of the real tradeoffs? This
common practice is aptly known in our trade as turd polishing.
841,500 is the number of software professionals according to an estimate in the IT industry in India.
Assuming most of the IT companies follow the forced ranking that I talked about in my previous post, the question that I have is….where does that leave the 42,075 employees who fall under the bottom 5%?
42,075! That is as high a number as the current strength of the likes of the top IT companies.
Here is what happens….all organizations have different time-frames within the year when they carry out this exercise.
For simplicity sake, assume 3 large organizations with an employee strength of 30,000 employees each doing their Appraisals/Forced rankings once every year at different point in time say January, June and September respectively. Each of the Organization creates approximately 1500 dissatisfied employees during these months….natural consequence of the process, employees from org A quit and go and join B, where the process repeats itself and the 1500 from B go and join Org C … meanwhile Organization A and B have approx 1500 seats that they need to fill in and more given the fact that they would have more business……and it is no surprise that the Org B would be willing to hire the bottom 5% from Org A at a higher designation and higher pay and Organization C hiring the bottom 5% from Org B and so on.
And interestingly no one would concede that they are hiring anyone less than the best!
Interestingly, Joel, earlier this year, wrote an awesome post titled "Everyone thinks they are hiring the top 5%".
Johana Rothman maintains two must read blogs - Managing Product Development and Hiring Technical People. I have been following her blog for more than a year now. In her latest post she comments on a paper published in Workforce Management on Forced Ranking.
If you force rank — even once — the people who find this offensive
leave. (I did when I worked for a VP who believed in forced ranking.)
So, you quite successfully build a culture where forced ranking is
valued. In my experience, you create a cut-throat culture, where it
matters more who gets ahead rather than making great products.
Perfect. Most IT organization’ have blindly adopted this model of forced ranking without even bothering to weed out the bottom 5 or 10% - that was the intention at GE when they started forced ranking. (Correct me if I am wrong out here). Having been through so many cycles of appraisals at various organizations, all that I see at the end of each cycle is a large pool of employees, red eyes, dejected, heart-broken, shoulders drooping and defeated just because they haven’t found a fitment into the right slot (which is always the top 5%)! While some like Johana quit and go, others tend to adapt themselves quickly to the system and play the game. I have seen so many employees engaging themselves in an engagement with a single minded view of managing their appraisal (cover your back…) …can’t blame them though.
The worst affected are the one’s who go through their first performance appraisal in life. Coming out of college, they expect their Managers to be like their college professor awarding grades and when they get a rating less than what they had expected, their self esteem crashes! My only piece of advise for rookies is not to equate performance appraisals with their exam grades and to remember that life is not always fair!
However I wonder as to why organizations cannot go through a more simplet process than this yearly tamasha of Appraisals and Ratings. I think that there is a much simpler way of going through the entire appraisal lifecycle instead of predetermining the percentages of exceptional, good, and bad employees and trying to retrofit the employees to the ratings and that is going the other way round that is:
- accept the fact that every employee is a human being and not a number.
- treat the employee with all fairness.
- set goals for the job she is supposed to do.
- when the job gets over, appraise her against the goals.
- If a manager comes back and says that the employee needs improvement, then he/she should state what actions he/she has taken to improve the employee’ performance during the time she was associated with that manager!
- A team is as good as its manager.
- Reset goals and iterate.
- Don’t predetermine the target of employees who would fit into a bell curve.
- if at all let the bell curve come out of a fair exercise, delight when you see that it isn’t a bell curve after all!
[Via Sadagopan] Paul Allen writing in Connect Mag says:
The paradox for knowledge workers is
this: the more time you spend in gaining knowledge, the less time you
have to apply it. The reverse is also true. We must strike a proper
balance between learning and doing. Most people have their nose to the
grindstone. Very few spend enough time, energy and money in a quest to
gain and process knowledge. But maybe the Web can change this. With the
Web, each of us can make a list of all the experts in our field and
track their every move and their every word.
With modern knowledge tools, each of us
can design our own lifelong learning curriculum including books,
articles, Google news alerts, TV programs, and audio programs and
seek to become experts in our field and in our particular occupation.
This is sound advice and however much we tend to get caught in the day to day grind, it pays to devote some time to enhancing career development skills and as Allen rightly says, with so many tools at our disposal, it will be foolish not to sharpen the saw daily!
Way back in early 90’s, my brother and I were having a conversation around the theme as to how software development was more closer to making a movie. For some reason, this conversation stayed in my mind and I distinctly remember that it was right after a TV show featuring Subhash Ghai where he talked about different aspects of movie making.
Mats Wessberg writing in Developerworks @ IBM uses the same analogy in his article "Introducing the IBM Rational Unified process by Analogy", where he talks of "How is software development like moviemaking"
Making a feature film is a vast undertaking that involves managing a
huge crew and a substantial budget. Communicating well about needed
changes is vital to the success of such a project. Imagine that the
director wants to improve the final scene. Although it comes at the end
of the movie, the need for improvement can be identified early since
quality is continuously verified on all levels. Do the screenwriters
have to update the script? Who will review and approve it? Does the
scene have to be modeled again? If so, will storyboards, 3D graphics,
or plastic models be used? Does the set need to be modified, or does a
new set need to be built? Do we have to scout for a new location? Do we
need to call the special effects guys? How does this affect our budget?
Do we have to ask for more time and money? These are the kinds of
questions that result in changing plans and therefore must be
addressed, preferably in an iterative manner.
But the analogy that I liked the best:
If the functional requirements of software have their counterpart in
movies, can a movie also have nonfunctional requirements? The answer
(not surprisingly) is yes. Maybe (for commercial reasons) the movie
must be viewable by children under 18 and no longer than 120 minutes.
Although these requirements aren’t directly related to the story line,
they’ll have an impact on the final result — just as nonfunctional
software requirements must have on a computer system.
