Posts Tagged ‘Project Planning’

I’ve reblogged here for a reason a post from my other light-reading blog at http://ksriranga.wordpress.com/2014/01/31/how-to-hit-the-bulls-eye-every-time/ for your perusal.

Will catch up with you on the other side.

Begin Post:

How To Hit The Bull’s Eye Every Time?

The myth of 10,000 hours needed to become an ace at anything is busted. Read on to find out how.


One morning a Duke was riding inside the woods together with his men-at-arms and servants when he caught the sight of the usual target of concentric circles painted on a tree trunk and smack inside the center of each was a bolt.

Some distance away, he came up on another tree that too had the target and the arrow in bull’s eye.

He found more trees of the same kind.

“Who is this amazingly skilled bowman?” wondered the Duke. “Fetch him wherever he is. I have to meet him!”

When his retinue looked around they found a young boyish looking man with a bow and bolts. They produced him before the Duke.

“Lad, fear not. Who is the great bowman that had hit the bull’s eye every time? Do you know him?”

The young man shook his head to say he did know who did it.

“Is it your father?”

He shook his head again this time to say it wasn’t him.

“The teacher from whom you’re perhaps training?”

It wasn’t him either.

The Duke persisted with his query.

Finally the young man mumbled it was him that shot the bolts plumb inside the middle of every last one of targets.

The Duke laughed aloud: “I know – you didn’t essentially stroll up to the targets and sledge the shafts into the middle, did you?”

“No, my master. I shot them from 100 paces. I swear it by all that I hold holy.”

“That is really astounding, you’re the best archer I’ve ever seen. I herewith appoint you as a trainer to my archers.”

The young man thanked the Duke profusely.

“I still have a question to ask of you. How did you get to be so good hitting the bull’s eye every time? Did you spend all day practicing? If you’re so good, your teacher must be a wizard. Take us to him, will you?”


“No, No. It is like this. I stand upright, take a careful aim, hold my breath, see it with one eye and shoot the arrow at the tree.”

“Well, that’s what we all do too.”

“And then draw the target circles around where the bolt went into the tree.”

End Post .

Well, jest aside, it is the same thing with some projects. Result is what happens.

Result is not what is committed to the management or to the customer. And usually there are enough good reasons to explain why it happened. Such as extraneous environmental factors like weather or political sensitivity like a civic disturbance. Such as a customer deliberately or otherwise taking advantage of a poorly worded contract to expand the scope or demand services beyond originally envisaged. Etc. Etc.

The project manager is expected to foresee at least some of these risks and plan out mitigation strategies. If it is not done so or if the mitigation strategies are not effective, it is strongly advisable for the project manager to stop the continuing week-after-week agony, step back, rethink and re-plan with customer’s help.

What one finds, instead, is insufficient thinking and action to contain to whatever extent the impact of such uncontrollable developments. These are protrayed as given and the project lives from week to week.

If the factors are absolutely immitigable, then these must be factored into the contract and the original plan. Example: doing field survey in monsoon or severe winter. Though uncommon, I’ve seen projects executed in a start – stop mode these factors permitting. Another interesting example is where a more fundamental change in approach was needed as a solution to insurmountable problems – given the difficulties in freezing requirements with users in advance despite best efforts, the very methodology of developing software has undergone a transformation now using agile methods for success.

Barring those outliers (usually the R & D kind), can project outcomes also be as certain as taxes and death? We may not be there yet, but it certainly helps a long way if project management does not let reasons override results.


Read Full Post »

Here’s a fairly simple little story. Listen carefully.

It’s 4-00 pm and I call you in.

‘Look, there is a Mr. Singh staying in Hotel President. Do you know where it is?’

‘Yes, in Cuffe Parade (in North Mumbai). I’ve seen it.’

‘A proposal has to be reached to him before 6 pm. He has a flight to catch. It’s absolutely important that he gets this proposal before he leaves. You understand?’


‘I can’t trust this job to anyone else. I want you to drop whatever you’re doing and take this envelope to him. And there must be no goof-up of any kind. You get it?’


‘Now quickly tell me what else you want to know and get going. It’s a little tight going from here (Andheri, in South Mumbai). It’s like a project and how do you plan to go about?’

The story ends here.

This is one of the several scenarios I had devised to push the aspiring project manager and assess his responses. Back in those days we did not have PMI certification or any other equivalent to go by!

At this point some of you aspirants wanting to try out this role-play – stop reading further, as the game is given away in what follows.

If you’re done with the role-play, it’s time to look at the ulterior motives of the story.

This scenario, though crafted, is not very unlike real-life situations in projects. It has several questions to be resolved for the candidate even before planning the execution:

– Mr. Singh’s full name – ‘Singh’ is a very common name, to be found even among non-Sikhs. How is he identified on the guest list and visually too?

– How could one reach him on phone directly for coordination? No cell-phones, then.

– How much is the budget for transport?

– Is 6-00 pm absolute and non-negotiable or there is a margin?

– In the event of a delay despite best efforts, what should be done?

– What kind of an acknowledgement is due from Mr. Singh on receipt of the envelope?

– What kind of confirmation is desired during the execution and at the conclusion of the ‘project’?

The answers to these questions fill up important gaps in the definition of the project, the customer and the handshake and also ascertain performance parameters and prevailing constraints, at least the major factors.

Next is the planning process. There are 2 hours available to commute from one end of the city to the other end. In the slot of 4-00 pm to 6-00 pm the traffic on roads in Mumbai could be notorious in spots. Are these environmental risks factored, in addition to the permissible expense budget, to plan the route and the mode of transport?

In the execution process, again questions arise:

– How goes one sense the deadline would not be met staying on the current course? Are there intermediate milestones or check-points?

– If so, what are the switching options available to recover from or mitigate the delay?

– What office support could possibly be drawn upon during the execution process?

The story and the role-play go this far.

While the above is a direct presentation of the issues involved, in the assessment exercise I push the candidate helpfully towards some of the issues that he overlooks.

The scoring of the responses is not very relevant here as the main objective is elucidate on the issues and practices in project management through this story.

It was quite interesting to see how the candidates handled this simple ‘project’. The responses ranged from naïve, funny to some unexpectedly new insights that contributed to subsequent evolution of the story.

One candidate did not know any of the half-a-dozen destinations I pulled out one after another. She was new to Mumbai.

I remember how I had to plug the story after another aspirant steered the story entirely on a different course! Innocently, he asked: Couldn’t he meet up with Mr. Singh and handover the envelope when he reaches the airport, only fifteen minutes away, he asked, instead of trudging all the way to Cuffe Parade?


Credits: openclipart.com (jabernal) for the image.

Read Full Post »

Milestones are important in any paradigm of project management regardless of what tools are used to assist in project management. Carefully planned milestones go a long way towards success of a project and satisfaction of its stakeholders.

While a project may be reviewed in great detail by looking at the level of tasks, it is the milestones and their dates that aggregate the impact for easy comprehension of the bigger picture.

Now, is there a basis for setting up these milestones in a project?

While it is not exactly a science, some useful guidelines can certainly be framed to help in defining the milestones. A word of caution, of course, is in specific situation, these guidelines may be required to be adapted to fit the occasion.

Here we go:

Every important event in the life of a project is enshrined as a milestone. Usually these events mark the completion of a phase of the SDLC cycle for a module or piece of the system under development.

Associated with a milestone is a deliverable (code, document, bug-list…) of value to the stakeholders.

It is often overlooked the acceptance of the deliverable by the customer is also a milestone. It implies the deliverable is adequately tested by the vendor before delivery and is also sufficiently tested by the customer for its acceptance. The principle applies to all committments required from the various stakeholders for the successful execution of the project. And these milestones represent the committment of their owners (stakeholders) to the project. This must be impressed up on all at the very outset. It is not a solo show by the vendor driving all the milestones.

As far as possible, a milestone has a single stakeholder responsible for the deliverable. For instance, QC testing is normally done by an independent Quality group and hence gives rise to a separate milestone to mark that activity.

Obviously the definition of the milestones and their sequencing are settled jointly by the stakeholders, usually guided by the customer’s priorities and any inherent dependencies and risks.

Often a simple step is missed out of making sure all stakeholders are in the know and in agreement with the schedule of milestones. It has the potential for causing serious consequences. How often do we find the customer has planned his vaccation when the deliverable is required to be tested by him for acceptance!

A corollary of associating a deliverable with a milestone is to also link a quantum of payment by the customer to the vendor commensurate with the efforts towards the milestone.

The milestone’s deliverable must be ‘executable’ (verifiable), must represent a significant addition to the functionality delivered in the earlier milestones. And, even usable especially in the later stages of the project.

For this reason, it is a good practice to ensure the deliverable of the current milestone is completely integrated with the earlier deliverables.

In all but the simpler projects, at any instant of time, activities may be current on more than one milestone.

A key question still remains is: How many milestones should be defined in a project?

More milestones a project has, it is less risky for the customer. He has greater visibility into the project and sees it being ‘conquered by divide and rule.’ It is also less risky for the vendor as any lack of alignment of the deliverable with the customer’s needs is detected at the earliest point of time for correction. The down-side of having too many milestones is the overhead associated with readying the deliverable by the vendor and its testing by the customer for each of those milestones.

Obviously, it is the other side of the coin if there are too few milestones in the project. Besides, the vendor also gets paid later in the day for his efforts.

What is the golden mean?

Of course it depends on the size of the project. Well, a thumb-rule could be a vendor’s milestone for every 15% of the project efforts completed or for every 3 to 4 weeks of elapsed time whichever is earlier.

It is also not unusual to define a hierarchy of milestones in larger projects.

It is a normal practice to estimate and track other performance parameters besides the timeline for each milestone individually.

Hence, a high-level milestone or a set of milestones at lower level may be planned so as to include the all the phases of the SDLC cycle as completely as possible. Only then many performance parameters are meaningful. For instance Defects Density is meaningful for a milestone only if all the development efforts are included in that milestone.

And, finally, it is possible for the vendor to set up internal milestones not visible to the customer as part of the strategy to split it up into manageable pieces.


Do share your experiences in this regard.

Source: Image form Wiki

Read Full Post »


Let us go back to the order-entry example and its (single) business objective of reducing the time taken to enter error-free orders. We had developed a partial list of actions for assuring performance with regard to this objective, on two separate threads:

Business Execution thread:

– owner: customer, action: train end-users on orders and their entry.

– owner: customer, action: take up some process reengineering and rationalizing.

– owner: customer, action: make available end-users for training.

– owner: customer, action: adequate bandwidth to be provided to connect up with the back-end order-entry system.

IT Execution thread:

– owner: software service provider, action: train end-users on the new solution.

– owner: software service provide, action: design lightly loaded screens, minimize server visits…

– owner: software service provider, action: make the screens intuitively obvious, minimize clicks for main flow, use technologies like Ajax for rich user interface, generate meaningful error messages, provide useful defaults, drop-down selects, auto-fill, etc. to reduce data entry effort.

– owner: software service provider, action: include in requirements and design the feature to save a partially filled order; also it should be possible for another authorized user to later complete the partially filled order.

The customer’s organization owns the Business Execution thread while the IT Execution thread is driven by the service provider. In this example, there are only two broad organization-level ownerships shown. In general, there could be more specific roles, drawn from the stakeholders and their organizational structures.

Also, the actions read generic in the above. In real, they could get quite context specific in terms of the intents and measures (see examples below).

Some of the actions directly map as activities of a project plan. Example: training end-users on the new solution. And, some could go under SDLC guidelines for the project, gross or fine-grained. Examples: [A design guideline: the landing page should not exceed 60 kb]; [A feature-level coding standard: stored procedures handling multiple on-screen selections should use of table variables for simplicity and speed (this is fine-grained)].

Now, the guidelines strongly emanate from business objectives instead of degenerating into a huge ‘cut and pasted’ linear list. Even if the guidelines are already in place and not generated in this manner, it would still be useful to validate them along these lines to fill the gaps and weed out the unimportant. For instance, it may show that certain business-level failure syndromes may not have sufficient guidelines to protect – a gap to be plugged. It may also be possible to apply a sense of priority to the set of SDLC standards which always threaten to get prolific and often in mutual conflict.

Incidentally, an earlier post ‘Coding Standards – a chimera?’ spoke of the importance of relating the coding standards to architectural attributes and other keys. Here we are enlarging it to relate all SDLC standards as strongly as possible to business objectives which in turn form the basis for the said architectural attributes.

Preemptive planning of this kind significantly enhances assurance of achieving intended business objectives.

In summary, the submission made here is to recognize and plan in a Business Execution thread in mesh with the IT Execution thread which usually is all of a conventional project plan. This stems from conceiving a project to include the main purpose of achieving business objectives instead of limiting it to software deliverables as is the current practice. With it, the clear statement that business objectives have a greater chance of being realized only if both the customer and the service provider plan and work together from day one with an end-to-end vision. On this road, the SDLC standards stand out with definite prioritized purpose.

Extending the scope of a project beyond the limits of software deliverables is an opportunity for the service provider to provide tangible business value, fraught with interesting possibilities for ongoing engagement with the customer. If ERP roll-outs are planned and executed along these lines (not the whole nine yards yet), why not bespoke development?


Read Full Post »


More on the actions that go into Business Execution and IT Execution threads and some new opportunities for service providers:

In a typical ERP roll-out, most actions go into the Business Execution (BE) thread. There would be actions in the IT Execution (ITE) thread to install, configure and customize the solution. But these actions are driven by actions in the BE thread.

Should that not also be the case with non-ERP solution development and roll out? Since the solution is being developed and is not ready off the shelf, that happens to be an intensive set of SDLC actions. Nevertheless the interlock with the BE thread must be maximized so that course corrections if any are applied at the earliest point of time.  Obviously these interlocks must be purposefully arranged for productive use of the customer’s time and not be contrived.


There is this famous curve usually produced often in project kick-off meetings which shows the actions on part of the customer and the developer in a typical SDLC project, without formally identifying the two threads as we have done. The customer involvement peaks initially during requirement gathering phase, drops off during the design and coding phases and again perks up during the acceptance testing phase. This is more the case in waterfall execution and can be adapted suitably for other paradigms of development as well.


The traditional SDLC model does not stretch itself (while ERP roll-outs may) to cover successful roll-outs. This is a crucial activity and the solution developed morphs into shelf-ware if the roll-out is not handled with professional competence and precision.


There is an even more important question of whether the business objectives of the project as originally conceived by its sponsor are achieved thru the usage of this solution. This immediately implies a period of usage on part of the end-users after the roll-out.


The ERP world makes a weak attempt by way of a post-implementation audit service, while the traditional SDLC model completely disassociates with this question. So, between the roll-out and the audit, who is concerned with the progress made? Can it be left to the customer to drive this march without any inputs of professional expertise? What are those sign-posts for success and the failure syndromes? Shouldn’t there be a well-planned and sustained effort during this critical phase? Note this is different from the L1-L2-L3-L4 support of Application Management Services.


The plea made here is: this is a definite opportunity for the service provider to enlarge his bouquet of services and value he delivers to cover these milestones and the customer has some reassurance towards achieving the intended benefits.


Some mature customers even now do plan end-to-end and arrange for themselves assistance of this kind either from the service provider or from some other agency. In any case there seems to be a clear need for formally structuring the actions and defining the services and deliverables associated with the two milestones. And plan them in from the ‘go’. This can also lead to some risk-reward models for the service provider, once these services mature.


(More to follow)

Read Full Post »


A software service provider (applies to internal IT too) usually evaluates his own performance in regard to his customer’s projects on costs, effort and timeline. A project is considered successfully completed if the targets are met on these metrics. While a project may be successfully completed and deployed, it may not still achieve end-to-end business objectives set out initially by the project sponsor in the business case, for various reasons. The one reason is that often the service provider only sees the requirements detailed out to him and not the business objectives themselves. Could the project be planned more holistically if the service provider is exposed to the business objectives as well? Let us see how this could be done.


For example, consider the business objective: the time taken to enter an error-free customer order into the system needs to be reduced (metrics omitted).


For assuring performance in regard to this objective, it is translated into a set of actions necessary on part of the stakeholders.  These actions could be developed using any method. Here, we imagine the contrary, examine reasons and develop preemptive actions.  


Continuing with the above example of order-entry, the business objective of reducing the time taken to enter error-free orders may not successful because of one or more of the following reasons (alongside, a possible preemptive action to protect against this cause of failure is indicated and its ownership):


– The end-users (customer’s order-entry personnel) are not familiar with the business aspects of a customer-order especially about the changes from earlier practices (owner: customer, action: train end-users on orders and their entry).


– The types of customer-orders and their entry are too various and difficult to comprehend (owner: customer. action: take up some process reengineering and rationalizing; however, much of it could lie outside the scope in the current context of developing a software solution for order-entry).    


– The end-users are not trained on effectively using this software (owner: software service provider, action: train end-users on the new solution; owner: customer, action: make available end-users for training).   


– The system is sluggish in its responses when an order is entered (owner: customer, action: provide adequate bandwidth to connect up with the back-end order-entry system; owner: software service provide, action: design lightly loaded screens, minimize server visits…)


– The users have to do more work to get an order entered into the system (owner: software service provider, action: make the screens intuitively obvious, minimize clicks for main flow, use technologies like Ajax for rich user interface, generate meaningful error messages, provide defaults to reduce data entry effort…).


– If the order-entry is interrupted for some reason, user has to start all over again (owner: software service provider, action: include in requirements and design the feature to save a partially filled order; also it should be possible for another authorized user to later complete the partially filled order). 


The above list though not all-inclusive is sufficient for making the point.


Realization of business objectives in a project could be viewed as a combination of ‘Business Execution’ and ‘IT Execution’ threads. Actions such as rationalizing order types and their processing, training the end-users, etc. come under Business Execution thread while actions of SDLC and infrastructure kinds go under IT Execution.


Now the point being made is: a unified project plan must include actions from both the threads for assurance on the achievement of the business objectives, and their synchronization. Even though it is still only an assurance and not a guarantee for results, this holistic approach is likely to yield better end-to-end results. This is in sharp contrast to the current practice wherein the Business Execution thread is at best a diffused set of activities and ownership, and not tightly managed. And the business objectives are not very visible to the service provider.


It is not as if the all actions in Business Execution thread are owned by the customer and similarly all actions in IT Execution thread, by the service provider. Example: owner: customer, action: provide adequate bandwidth to connect up with the back-end order-entry system goes under IT Execution thread as mentioned earlier.


It would be nice if the planning tool allows the threads to be managed individually and collectively in a composite plan with all interdependencies coded.


Who manages the Business Execution thread? A simple straightforward answer is a manager designated by the sponsor in customer organization. Depending on the kind of activities on this thread, other variations are possible. In simple cases, the service provider’s project manager could assume overall responsibility, keeping in mind that the project management competency is what he brings to the table. Even now he manages actions that call for heavy participation of the customer: scope management, change management, risk management, knowledge transfer, testing and approving deliverables. This enhanced responsibility is clearly an opportunity for the customer to derive more value from the service provider and for the service provider to differentiate his services.


Regardless of who manages it, the Business Execution thread is recognized for what it is, planned and meshed with the IT Execution thread.


On the side of the business, it is no longer the traditional role of someone acting merely as the single-point contact for the service provider. It is a more demanding role of one who manages an important thread of actions in the project.


(More to follow)

Read Full Post »