Year in Review

2005 has come to an end. For me, this would be the year where the most contigencies have happened, and almost impossible to plan. Or perhaps I should use the old saying: "What man proposes, heaven disposes".

My friends and colleagues would know that I'm the type who likes to plan ahead, be it the annual vacation, getting married, moving house, etc. But this year, the guy upstairs seems to enjoy throwing things in the way of my plans.

Well, my wife and I have been planning to start a family for quite a while. Things haven't been happening quite as planned, so when my project work provided an opportunity for me to be posted overseas, my wife and I agreed that it would be a good break for us (to get away from the pressures to procreate, to allow me to focus on just one project and in technical work, to nudge my wife out of her comfort zone for a while).

Just 2 months before our departure, my wife and I had the good news we were waiting for. It was like the last month that we "let things go naturally"; if we had missed this one, I'd not be typing this from my home now.

So, we had to backpaddle and put an emergency brake to the posting, make adjustments to both our work (my wife has already obtained the no-pay leave she requested and started to hand over some of the work; I had to explain to everybody that I'm not going after all and make arrangements for the project and my workload).

Because I was not going overseas, and because of my dis-satisfaction with my involvement with this project, I started to request for transfer to other projects, getting the project manager to sort of agree that I will transit out by the next milestone sometime in 2006.

Just as I was happily washing my hands off the project, my project manager had some personal issues with his family, and had to be away for quite a while. And I had to cover his project management duties, an instant reversal of my planned extrication from this project.

This took me all the way to the end of the year. Come 2006, I'm not planning for anything, just waiting for things to come. What with my first baby coming, and still not sure when my project manager will be back fulltime on his job, all I can do is to take things one step at a time.

Wishing one and all a happy, healthy and fruitful 2006.

Software Project Manager's Handbook by Dwayne Phillips

So Dwayne says that project managers must basically like to work with people. I guess most of the project managers become project managers either because they are good at technical work, or simply outlasted the competition (i.e. stuck around long enough).

Come to think of it, most professional services industry suffer from the same thing (accounting firms, law firms) ...

Recent Updates

Have not updated blog entries for a while. Guess I've gotten over the peevish stage with my Project Manager, so have not had the emotional upheaval to require an outlet to write.

A combination of factors helped to resolve my bout of peevishness. I was supposed to be posted overseas for a stint, but things came up at home that I had to cancel the trip. The trip would have helped to reduce the friction between the project manager and I, but now that it did not happen, I was thinking about making a shift to another group, when the director (our collective boss) talked to me in the corridor and mooted the idea first. His concern, rightly, was that there isn't a clear role for me in the project. I was pretty much like a "deputy" project manager. I am rather grateful to him for making it easier for me by initiating it, instead of me trying to raise the issue without hurting anybody, especially myself. Anyway, so I am moving out of the project after the design phase.

This provided an opportunity for me to raise the issue to my project manager, and I also made use of the opportunity to scope out a "role" in the team, in essentially the simulation team. With this, I deliberately chose to skip the customer's project management meetings. Skipping the meetings helped, because when I attended, I became essentially the "messegner boy", and often felt the pressure from the customer because of all the issues that remained happily outstanding in the project manager's lap. Now, they are breathing down HIS neck, and rightfully so, as I did not have the authority to direct the project resources anyway.

Strange thing is that, now that I'm staying away, the idea of attending these meetings no longer irk me as much, and I do find myself attending some of them recently. I should remind myself not to get overly involved again. Like the Chinese saying: "Distance is Beauty".

It is working != It is correct

I wonder how our local universities teach programming. Wait, I am a product of these universities ... well, guess I can only say that they're as wanting as before.

A couple of weeks ago, I had to lecture one of my junior colleague, just out of U. It's not because he's not good, or the code's not working, but something just got on my nerves. Maybe I should illustrate with an example.

Light, as we know, comprises 3 primary colour components. So, we can have a CLight class which has 3 CPrimaryColourComponents. Each CPrimaryColourComponent has a integral value denoting the intensity, and an enumerated type that states whether it is BLUE, RED or GREEN.

We can have

enum E_COLOUR_TYPE
{
RED = 0,
BLUE,
GREEN
};

In fact, this was defined, in a header file that includes a whole bunch of other stuff that is totally unnecessary for the simple remote data sender/receiver thing I asked him to write. So, I used integer instead, something like:

class CPrimaryColourComponent
{
public:

int getIntensity() const;
void setIntensity(int intensity);

// 0 for RED, 1 for BLUE, 2 for GREEN
int getColourType() const;
void setColourType(int colour);

};

class CLight
{
void setPrimaryColour(int colour, int intensity);
const CPrimaryColourComponent & getPrimaryColour(int colour);
};


Initially, the code looks fine. We were doing stuff like

CLight myLight;
// ....

myLight.setPrimaryColour(0, 23);
myLight.setPrimaryColour(1, 44);
myLight.setPrimaryColour(2, 32);

// ...
int redIntensity myLight.getPrimaryColour(0).getIntensity();
int blueIntensity myLight.getPrimaryColour(1).getIntensity();
int greenIntensity myLight.getPrimaryColour(2).getIntensity();

My mistake was that in the portion of the code that marshals the data across to his module, I got lazy and directly cast the integral value of the CPrimaryColourComponent's ColourType to the enumerated value, e.g.

E_COLOUR_TYPE colType;
int colIntensity;
// ....
myLight.setPrimaryColour(colType, colIntensity);

CPrimaryColourComponent = pcComp;
// ...
E_COLOUR_TYPE pcType = pcComp.getColourType();

In CLight, there's an array of CPrimaryColourComponent, each element holding 1 CPrimaryColourComponent, indexed by the Colour type (Like I said, this was meant to be a simple stub thing).

Of course, after a while, the E_COLOUR_TYPE had to be changed to

enum E_COLOUR_TYPE
{
RED = 1,
BLUE,
GREEN
};

Instead of changing the mapping routine which I have passed to him for maintenance, he changed the implementation of CLight::setPrimaryColour(...) such that now, we call

myLight.setPrimaryColour(1, 23);
myLight.setPrimaryColour(2, 44);
myLight.setPrimaryColour(3, 32);

However, the portion to retrieve the colour components was not changed:

int redIntensity myLight.getPrimaryColour(0).getIntensity();
int blueIntensity myLight.getPrimaryColour(1).getIntensity();
int greenIntensity myLight.getPrimaryColour(2).getIntensity();

Essentially, the CPrimaryColourComponent array index was offset by 1 in the set function, but not offset in the get function.

I exclaimed that one cannot design a class where setPrimaryColour goes from 1 to 3, and the getPrimaryColour goes from 0 to 2. It's plain inconsistent and confusing.

The strange thing was that he found me somewhat puzzling. He was probably thinking what's the big fuss, the code's working. He also thought I had wanted to access the array with an index from 1 to 3 and expressed concern about wasting one array element. I had to tell him that it's got nothing to do with however he intends to store the CPrimaryColourComponent instances, but it is wrong from the CLight interfaces.

Until now, 2 weeks on, I'm still not sure he got my point ...

I feel like dirt.

I found out I'm going on an overseas trip this week. How? My colleague SMS'ed me when I was on course 2 weeks ago to ask about the validity of my passport.

Then I found out the arrival and departure dates. How? Another colleague emailed our overseas rep. A word document attached contains my name and the dates of arrival and departure.

Then I found out we couldn't get seats on the intended departure date (ex SIN). How? During a casual post lunch conversation with the first colleague.

Today I found out that because of the 2-day delay, my boss is extending the trip across the weekend (it was originally for 5 working days). How? Well, the first colleague just told me when we're in the lab working.

The strange thing is that there is no agenda set yet. So why am I going? In case they need me? Because I'm good at everything? So that my boss can throw me things he doesn't want to do?

5 minutes ago, I found out that the admin girl helping with the ticket arrangement isn't informed of the extension. I'm 101%, no 99.999% sure (leave myself some room to wriggle) that hotel arrangement isn't updated.

So far, my boss has not come to me and inform me that I am on this trip (although we ALL ASSUMED I was), when, and whether I can make it. I have to go around getting information from others.

Am I a machine? To be moved at will? To be switched on and off at will?

Should I feel like dirt?

Barriers to Project Planning

A common situation in planning is that people do not want to spend the time and effort to plan. They are paid to build systems and write software, not plan. These people do not like to plan and they do not plan well. This combination means that they often delay planning until the last possible moment or beyond.

Some people defer planning, hoping that additional information becomes available. Some think planning is a waste of time, because things always change anyway.

Planning well takes time and effort. Thus it is important to "plan to plan". Often, planning is done during the "spare time" of the project managers who are often on other work assignments. Effort spent on estimation, budgeting, and tasking is not accounted for. It is little wonder then that the project plans are sketchy at best.

A related problem is that project management is not perceived to be real work. When activities do get planned, few if any, actually plan in project management activities. Aside from schedule, there are many plans in a project, e.g. scmp, sqap, rmp, etc. Project managers often asked “If I had to do all that, how am I going to do the real work?”

These people fail to see why the plans came about in the first place, and/or refuse to give up their selfish desire to do technical work. They do not care/think that the project and the team members suffer because of the lack of planning.

There is an example quoted in the book that describes the consequences when project managers do not take time to plan. I'm sure many of us can see ourselves in such situations:

“People were in the middle of flurries of unplanned activities. Since there was no plan, people were confused as to what they should be doing. Since they were confused, they were too busy to make the plan. This cycle repeats itself endlessly.”

Another common situation quoted in the book is that Project Managers are asked not to plan, but to cook up a “right answer plan”. Someone with authority dictates the deliverable milestones. Hence planning became a farce to arrange (and shorten) tasks to finish on the dictated date.

"The project begins, the dictated deadlines passes with no deliverables, and everybody lives in agony until they finish."

The funny thing is people tend to accept dictated plans, and try to make them work. This is because
· such situations occur so often it becomes normal;
· the dictator is the boss; nobody likes (has the moral courage) to cross the boss.
· people no longer believe in the plan; these disengaged staff just work silently and watch the inevitable happen.

A related phenomenon is what I call "hysterical optimism", where people become overly optimistic about the schedule, timeline and resources.

Very often we fool ourselves into thinking “The people will come on board.” Or “The other subsystem will be late”, “we’ll get the money from somewhere else” and the infamous "I think we can beat that date."

There is no basis to these assumptions, hence "hysterical". One possible reason is that these people are pressurized into coming up with the "right answer plan" and become delusional. Another reason is that they are by nature overly-optimistic.

Goooogle me!

Hey, I'm on Google!

Project Planning

Planning starts when the Project Manager realises there are tangible items to be delivered by certain dates, identify certain activities needed to deliver these items, and assigns people to perform these activities.

For all but the simplest projects (e.g. a weekend BBQ for 8 friends), this is insufficient.

Firstly, time is not taken into account. Items have to be delivered by a certain date, meaning that activities would have to be done by a certain date, meaning that they need to start by a certain date. Furthermore, some activities need to be performed in sequence. Without planning, people may start certain activities to find that they do not have the necessary input. Some may finish their activities and discover that nobody wants the things they did yet. Some activities may start too soon, and some too late.

A very typical example of what happens in projects was given in the book.

“Gamma had a high level plan. The PM or system engineer used it to sell the project to their managers. The plan was on a view graph. After approval, they never replaced these viewgraphs with a real plan.”

From the beginning (6 months to 2 years ago) till now, I have not seen the “real” project plan. However, I cannot go to the PM and say that the project plan does not exist, because they will point to the high level plan.

Because of this, I feel that there should be 2 project plans. A high level plan with 1 or 2 levels of WBS and the major milestones is used for the customers and stakeholders. For the project teams, activities should be at individual level with duration at the week level. For big projects, this may require several cascading levels perhaps projects within projects (or programs in this case), but it is essential because ultimately you are telling somebody to do something by a certain time.