Showing posts with label ProjectManagement. Show all posts
Showing posts with label ProjectManagement. Show all posts

Saturday, December 1, 2012

Small Business - Success Factors

The following factors, in my opinion, are some of the key driving factors for the success of a small organization. While it is true that the same factors are useful for an organization of any size, the factors below apply more to a smaller organization than a larger organization, due to the lack of dedicated functional resources which are usually available in a larger organization.

* Cross-functional training
In any organization, ‘silo’-ization of information is a problem. ‘Silo’-ization is a term I use to describe creation of distinct storehouses of knowledge / information about the company, and it’s processes. Some of it is unintended, simply because it is a tad impractical to know everything about everything in your organization. However, sometimes it is also intentional. In the latter case, there can be several driving factors: 1. Employee insecurity in imparting information which they think may be hazardous to their continued employment 2. Employee inertia to hold on to an existing skill-set and to not evolve with time. 3. Lack of good communication within the team leading to distrust, 4. Or just plain old laziness. This problem gets compounded as ‘silo’-ization increases and usually has an adverse impact on efficiency and viability of an organization as a whole. To counter these

* Leading from the top
While leadership from the top is key for an organization of any size, I believe it has a special meaning in case of a small company. In a small company, you typically get to know people more intimately than a small organization since one has to wear many hats at the same time. Therefore, top management personality traits can have a significant impact on the employees.

* Documentation
Documentation is essential for:
- Maintaining project history over time.
- Keeping a record of KPIs ( Key Performance Indicators ) over the years and trending them to evaluate current performance. 

Wednesday, May 13, 2009

Planning vis-a-vis Execution...


Sometimes , when someone asks us: "Hey, you were going to do this task 'x-y-z', did you do it yet ?", we reply by saying that even though I have not done the task yet, but I am "planning" to do it in the future. It is at times like these that we must reflect and think if we were really planning to do that task in the future, or was that statement used more like an excuse.

One must always consider that a person is always recognized and remembered by what he or she has already "done", not by what he or she "plans" to do. For example, let's take the case of Mahatma Gandhi's famous Dandi march. Suppose, that it so happened that Mahatma Gandhi expired a few months before the march. Assuming here for a moment, that the Dandi march was until then, Mahatma ji's largest venture, would we remember him by saying, "Mahatma'ji was great, because he had planned to undertake the Dandi march"? Would we remember him by saying, "Mahatma'ji was great, because his planned Dandi march would have mobilized thousands of Indians and bolstered the non-cooperation movement?"

I personally believe that we wouldn't have thought so highly of Mahatmaji if his thoughts and ideas had remained crystallized as plans (i.e. never materialized). In other words, his Dandi march was appreciated and recognized, because it did happen, and despite all the hurdles it did get executed. The fact that the Dandi march did happen, and it did mobilize thousands of Indians is something which we give due credits for, to Mahatma'ji. Therefore, plans are not worth the piece of paper they are written on, if the plans themselves are not planned to be executed. The eventual measure of success of planning, are the achieved results and the results are only possible after execution. This post does not serve to undermine the value of planning. I recognize that planning is a very important tool in the success of a project, but planning must always be done with one eye on execution.

Thursday, June 12, 2008

Consulting

I am not the best consultants out there but I am learning since I have been one for just the past few months, and this post is to merely draw attention to some of the things which I have learnt as with my job till now,

Some observations.

1. There will always a gap between what the client wants and between what the developer thinks he has to deliver. Here is where the PM - Project Manager comes in. A PM's job is to be a bit of the client and a bit of the developer and a bit of ... well ... duuh a PM ! :-)) He has to be the one who realizes if a client's demands are ridiculous, and suggests the same to the client, in a much more polite manner ofcourse. In a similar manner, it is a PMs responsibility to convey to the developer that client's expectations are realistic. There can be many factors which can lead to a developer being non co-operative. Sometimes, a developer may realize that what the client wants is realistic and well within his reach, but, he may think that there is no real reason for the client to demand that feature / functionality. Therefore, it is the PMs duty to not just convey what a client wants, but more importantly, if the need maybe, *why* a client desires a particular functionality.

2. Sometimes a developer can have a really big ego and same goes for a client, and it is the PM's job to make sure that the job gets done, irrespective of the sizes of the egos of the people involved !

3. A consultant has to be a good listener. One important aspect of consulting is that pretty much every client is unique. Here uniqueness is defined in terms of: type of desired deliverables, cultural difference, organizational difference, legacy, type of business, type of technology preferred, nature of people involded, and last but not the least, the additional complications which are almost always there. More often than not, consultants are called in to take care of the uniquely special doo doo that a client is in. In such cases, previously existing solutions to problems do not exist by definition, and neither do industry wide best practices to solve such problems. Therefore, a consultant has to be willing enough to get close to the problem and realize it's unique nature.

More stuff will follow ! :-)