Aerospace Software

The Best Promotion Policy in Organisations

A non-DO-178B post after a long time.

Among the winners of Ignobel prize this time are three Italians who have "demonstrated mathematically that organizations would become more efficient if they promoted people at random."

Yeah you go that right - random, not merit based, promotion.

The three Italians are Alessandro Pluchino, Andrea Rapisarda, and Cesare Garofalo of the University of Catania, Italy.

Here is their conclusion extracted from their paper, The Peter Principle Revisited: A Computational Study

... we obtained the counterintuitive result that the best strategies for improving, or at least for not diminishing, the efficiency of an organization, when one ignores the actual mechanism of competence transmission, are those of promoting an agent at random or of randomly alternating the promotion of the best and the worst members.

 By the way, Peter's Principle States:

"Every new member in a hierarchical organization climbs the hierarchy until he/she reaches his/her level of maximum incompetence."

I can imagine the management gurus squirming after this mathematical confirmation of Peter's Principle.

But then you always knew this, didn't you? Promoting an excellent software engineer to a managerial post is a sort of double whammy: You lose an excellent technical chap and get a lousy manager.

But before you go on to implement the new promotion policy, please have another good look at the conclusion. The words "when one ignores the actual mecahmism of competence transmission" hold the key to merit based promotion. Think about it!

Estimating Verification Effort

Continuing on estimation techniques ...

Have you estimated the time and effort it will require to complete verification for your project? Sure? 

Now go ahead and double the effort. Most of the DO-178B projects fail as the effort of verification and its impact is almost always underestimated. 

All of us know that no software development is a classic waterfall method but we estimate as if it is. As a result, we fail to take into account the feedback loops that verification generates. That's where the problem lies.

As a rule of thumb I recommend you immediately double your allocated time budget for verification effort. You can start refining from there.

A Perfect Estimation Technique

This is an extract from a wonderful book, Think Twice, written by Michael J. Mauboussin. I would like to believe that finally we have a perfect technique for estimating projects.

The extract ...

People find it hard to estimate how long a job will take and how much it will cost. When they are wrong they usually underestimate the time and expense. Psychologists call it the planning fallacy. ...

[But here is] an interesting twist. While people are notoriously poor at guessing when they'll finish their own projects, they're pretty good at guessing about other people. In fact, the planning fallacy embodies a broader principle. When people are forced to look at similar situations and see the frequency of success, they tend to predict more accurately. If you want to know how something is going to turn out for you, look at how it turn out for others in the same situation. Daniel Gilbert, a psychologist at Harvard University, ponders why people don't rely more on the outside view. ... The reason is most people think of themselves as different, and better, than those around them.

So, there you are. The best method of estimating any project would be:

a) Shed your ego.

b) Rely on historical data available in your company

c) Or if historical data is not available, simply ask others how much time they think you will take to complete a task.

  

Minutes Of Meeting Is A CC2 Control Item

Did you know that the DO-178B recommends that any data that aids the certification process should be subject to at least a CC2 control?

As an example the document cites Minutes of Meeting (MOM).

From experience,  I can tell you that an essential element in control of outsourced projects is regular teleconferencing. (Regular status reports help, but there is nothing to beat a weekly telecon.)

So, I would recommend that any telecon be converted into a formal MOM and configured as per the CC2 provisions, even if the telecon has no action items.

Thoughts On Hype Over Leadership ... Continues

I have posted on this iconoclastic book Hard Facts, Dangerous Half-Truths & Total Non-Sense in my other blog before. Readers who are familiar with Hard Facts ... therefore shouldn't be surprised that the most objective criticism of leadership comes from here.

I have also posted my views on leadership here & here. So naturally I was quite pleased to get supporting material from two professors from Stanford.

Hard Facts ... has a complete chapter (Are Great Leaders In Control Of Their Companies?) dedicated to leadership where it explores (explodes?) the myths of leadership.  I reproduce a few relevant text.

History is filled with leaders who make a big difference in the world: Gandhi ... Martin Luther King Jr. ... Queen Elizabeth I ... Winston Churchill ... and Lyndon Johnson[.] ... Leaders make a difference on a smaller organizational scale, as well. [S]ystematic quantitative research demonstrates that leadership can influence organizational performance. ... Leaders not only influence indicators of performance such as sales, profits, productivity, or budget allocations, they also affect their organization's interpersonal climate and the satisfaction and mental well-being of those they lead. ...

Nonetheless, leaders and managers often have far less influence over the performance than most people think. ... One study of the performance of 167 companies over a 20-year period sought to allocate variation in performance to the effects of industry, year (time period, which presumably measures general economic conditions), company-specific effects, and the change in leadership. Not surprisingly, the conclusion was that company and industry had much larger effects on variation in sales, profits, and profit margins than did changes in leadership. [M]ost [scholars] agree that the effects of leadership on performance are modest under most conditions, strong under a few conditions, and absent in others. 

I could go on and on quoting this book to prove my point that leadership is a function of followers and circumstances.
By the way, Hard Facts ... goes on to list fundamental guidelines for what leaders should do. It is a good read.

Leadership is over-hyped and what are you supposed to do about it

It is more or less accepted by all that the leadership as a function is distinct from management. There are areas of overlap but by and large when one talks of leadership it is very clear that one is not talking of management. (In fact, there is a tendency to look down upon management - what is your reaction to a kid who says, "When I grow up I want to be a leader" and to a kid who says "when I grow up I want to be a leader"?)

The easiest way to explain the distinction is by putting it in term of "are we doing things right?" (management) versus "are we doing the right things?" (leadership). This may be crude but I think summarises the distinction well. (By the way, this very definition - doing the things right v/s doing the right things - can be used to define Verification and Validation.)

Once we know that the functionalities differ, the next important step is of course to list down the attributes of a leader. Tomes have been written on this. The deluge of material on what makes a great leader is matched only by the material on Leadership styles. Just go here to see the 12 leadership styles that are in existence. There is also a charter of leadership that lists 10 essential qualities of a leader, the first of which is "Leading by example ..."  which seems to me like a explaining leadership in terms of leadership.

In any case, so many styles of leadership only goes to prove that leadership is situational. But what has been irking me most, of late, is the attempt to define characteristics / attribute / charter of a leader. Apart from the fact that we are being "fooled by randomness", this defining of attributes of a leader means that we are able to distil out those characteristics that make a great leader and are as easy as pills to ingest and digest. This assumes that qualities in human beings are separable and do not interact with each other.

A human being - any human being - is a product of ALL its attributes. They cannot be separated into water-tight compartment. If a person is irascible and is able to take effective decisions, we cannot say that the attribute we need to imbibe from that great person is "capability of taking effective decisions". It is as if once we "learn" how to take effective decisions, we can continue to act normally except when decision has to be taken. Then we just turn on the required attribute and apply. I wish it were that easy.

The essential element of a leadership scenario is followers or those who are being led. The rationale behind "being led" could be only that the follower believes that the leader will lead him/her to his/her goals (whatever they might be). So the only invariant is the followers willingness to follow. Hence, the leader only needs to convince the follower by his deed and actions that he will lead the follower to the cherished goal(s).

That was one long preface ...
Now let us take this in context of our work. Each of us have leadership qualities. When we take an initiative we display such qualities. When we come up with a plan to resolve a problem, we do it again. When we convince our subordinates to stick to the plan even though at first it doesn't seem to be working at first, we are leaders at that moment of time. What is left is the respect you need to gain from your followers. That's where my previous post comes in. As you continue to perform well as managers, the opportunities - however insignificant - for displaying leadership skills will arise. Every good decision will make you more confident of your skills and at the same time lift you in the eyes of your eventual follower(s).

A good manager may or may not go on to become a great leader but a bad manager will never be a great leader. And that is something I know for sure.

Be A Good Manager. Leadership Will Follow

Leadership cannot be learnt.

Why do I say this?

Because learning would require either emulating someone or inculcating best practices. It could also mean learning from experience.

There are two aspects to consider:

1) Empirically,
Leader = function of (follower, circumstances)

To be a leader you need followers (recruits in military are not followers nor are employees in the company). And there have to be circumstances that propel a person as a leader. Since each of the variables (follower, circumstances) will differ in time and space, emulating or best practices is at best guidelines.

But even the guidelines won't work. See point 2 below.

2) The sample size is too small and biased. I take off from "Fooled By Randomness". We can study the characteristics of a set of leaders and come to a set of parameters - such as vision, belief in him/herself, values, etc. And come to a conclusion. But we are studying only those who have become leaders having all these characteristics. We do not know of all those who had these characteristics but could not become leaders because they did not have the right followers and the circumstances were not right ("ahead of his time" people would say later) . To put it more "scientifically", we cannot establish a causal relation between these characteristics and leadership.

To summarise. Leadership cannot be learnt. In fact we should not even make an attempt to learn it.

What I recommend is as follows:
a) Being a manager can be learnt. Be an excellent manager.
b) In your role as manager you will come across situations where leadership needs to be exercised. You will evolve as you learn from the mistakes and correct things done to deal with the circumstances.
c) Keep an eye open for windows of opportunity.
d) When it comes, go for it.
e) You may emerge as a great leader.

Project Scheduling - A Few Tips

A few pointers to scheduling that is generally not found in text books:

1) Always evaluate risks before attempting a scheduling exercise. Use the Work Breakdown Structure and try to have at least one risk identified for each Work Package. Later on as the schedule is being developed, try and develop a risk for each activity. The question to ask: "what factor could cause a delay in this activity?" Try to come up with a response other than "absence of critical resource" or "critical resource falling ill".

2) There are two types of schedule - one that is given to the customer and the other that is for internal purposes. For obvious reasons the internal schedule needs to be tighter.

3) While preparing risks, keep the customer schedule aside and do not look at it. The internal schedule should show what is feasible and not what is required. The schedule can be reconciled later on.

4) Use a tool such as MS Projects to develop a Gantt Chart. At first your team will resist the use. Convince them about the advantage. If required force them to use it. To me a Gantt Chart and a schedule is synonymous.

5) Include impact of risk in the schedule. This can be done by defining separate risk activities and linking these activities using standard dependencies (such as SS, FS, SF, etc.) I find this more effective then using statistical techniques such as The Three Point Estimates (also called the PERT method). Let me explain what I mean. Assume the risk to an activity X could cause a delay of 3 days. In the Gantt Chart have an activity called Risk_X. The duration of this activity will be 3 days. Then link the activity Risk_X to Activity_X using Finish-Start dependency.  If during the project, the risk causes a delay beyond 3 days, this will get reflected in the actuals.   

6)  While preparing Gantt Chart link up as many activities as possible. The 'robustness' test of a good Gantt Chart is as follows: assume the maximum duration of the project is 4 weeks, push any activity by, say, 3 weeks. All the subsequent activities should move. If something is not moving then the Gantt Chart needs a relook. Try this on all activities. In any case, pushing any one activity by such a huge margin should definitely have an impact on the last activity of the project. If not, something is definitely wrong.

7) Build a holiday calendar of your own and incorporate that in the Gantt Chart.

8) Generally, at the time of preparation of the schedule, the actual people to work on the project is not decided. It is therefore a good idea to have a relook at the schedule once the project is peopled. Analyse the impact of the 'personal leave' calendar on the schedule. And the impact of the actual skills. By this time the schedule has already been frozen and sent to customer (internal or external). However, it is worth doing this so that additional risks and their mitigation action can be generated.

9) And finally, keep revisiting the schedule daily. It will help you keep information on your fingertips.

Notice how my points keep ending at 9. So, go ahead fill up the number 10 spot. 

You Have Assigned Tasks. Do You Follow Up?

You have make a plan using MS Projects. Assigned tasks. Set up a monitoring system that gives you the status of the work at the end of the day. But wait. Do you follow up?

There are a hundred of instructions that you throw in between tasks. These needs following up.
Actually all tasks need follow up.
And that does not mean management by exception ("if the status shows deficiency, I will follow up"). That doesn't work. That is passive. What I am talking about is active follow up.

Let's assume, half way through the project the customer wants a slight change in the template ... to be implemented here on. You have passed the information. But did you follow up? Did you see if everyone has understood the small change? Did you take up a few configured item to audit of the changes are in place?

The quality team's audit has pointed out an error in one of the products. You are wise. So you take immediate action. Every member of the team now knows the nature of the error and they have been instructed to avoid that. But did you follow up? Have you performed random audits of your own to see if there are no more errors of similar nature.

The process I follow for following up is as follows (I call it the quarter-point follow up):

1) Delegate with a deadline.
2) Set up a pop-up calendar notice to myself and the person who is delegated with the work at a quarter of the duration of the task assigned.

3) Follow up without procrastination.

So, if I have asked a person to develop a procedure document to be completed 4 weeks from today, I will set up a notice 1 week from now. And when the notice pops up on my desk top, I attend to it immediately (if possible) or within two hours of the pop-up (definitely).

It gives us enough time to implement mid-course corrections.

And if there is a mid-course correction required, have another quarter-point follow up as described above.

This might seem like micro-managing, but actually it is not. It is just a system that ensures no last moment panic. A quarter-point follow up also ensures that the work is distributed evenly over the entire period of the duration allotted and the student-syndrome (term borrowed from The Critical Chain) of pushing the bulk of the work towards the end is avoided.

The Most Important Task of a Project Manager

For a long time I considered Risk Management as the most important task of a Project Manager (PM). Since action speaks louder than intention, I always considered PM's ability to have a bird's eye view on a project best translated into raising risks.

For those who are not familiar with the Project Management Institute's Project Management Book of Knowledge (PMBOK), PMBOK defines risks as follows: "Project Risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on at least on at least one project objective."

Therefore the PM needs to continually compare where they are vis-a-vis where they should be, much like a controller of a feedback system.

No longer. I do not consider Risk Management as the most important task of a PM. That position has been usurped by "Being There".

Here's why.

1) The PM needs to be there to take decisions when the technical team is prevaricating.

2) The PM needs to be there when the technical team is grappling with prioritising tasks.

3) The PM needs to be there when the technical team is struck in a rut (doing the same thing again and again)

4) The PM needs to be there to stop work and ask technical team to take a step back to obtain a better picture.

5) The PM needs to be there to ensure that all members of the technical team are not trying to solve the same problem.

6) The PM needs to be there to comfort the team and say "tomorrow is another day" when at the end of the day nothing works.

7) The PM needs to be there to tell the customer that his/her team is working hard to meet impossible deadlines.

8) The PM needs to be there to sort out ego clashes and cool down frayed tempers that come about because of project stress.

9) The PM needs to be there to know what the hell is happening.

Don't want to make it a 10-things-that-PM-needs-to-do list. So I will stop here. Please feel free to add.