Wednesday, December 30, 2009
Tuesday, December 29, 2009
Monday, August 3, 2009
Saturday, May 23, 2009
Sunday, May 3, 2009
- Keep the end in mind - very often it is "courses for horses". You do fit your organization to the best people you have, period. Hence, neither your organization structure nor your role definitions for the new structure will be perfect. It is critical to identify what are the 1~2 items that you will NOT compromise [ Example, when establishing a program management organization, having it function neutral may be a critical rule. You can still accommodate people and new structures , provided you stick to this broad rule]
- Changes have to be enforced once decided. There are 3 techniques - most textbooks talk of just two to handle the resistance to change
- (a) Carrot - make people comfortable and show them the possible growth paths/career plan in the new structure
- (b) Stick - make organizational compliance mandatory. Preached easily, but difficult to practice with your best guys
- (c) Inaction! or wait - Several fears arise due to fear of the unknown. In any change management effort, the only way to overcome this residual fear, is not by more written definitions, but often , by pushing the people into their new waters and waiting for them to settle down. [For those of you who have travelled by Indian Railways, passengers are finicky and fight for their seats only till the train starts. For the next 6-10 or 24 hrs they all settle down into well oiled positions without any external intervention. This is probably cultural, but then thats what change management is all about!!]
Tuesday, April 21, 2009
To make a metrics program successful, the 1 or 2 (at most) reports should be branded with a name. Branding and retaining the key metrics into a report say Q25 or T20 or 9box , enables recall and drives continuity to a changing/improving set of metrics.
Further, this can also be incorporated into training programs / presentations at all levels to ensure importance and recall. A generic non-branded report such as a project report can easily be abused / modified and mis-understood diluting the needs of project reporting.
Tuesday, April 7, 2009
Sunday, March 29, 2009
Most senior management expect the PMO to be aware of risks in projects based on (1) their interactions with project teams (2) cross project experiences
The 3 levels of maturity of a PMO are
1. Initial: The PMO is still getting to be aware of the programs/structure and processes. Further, the rapport with the program manager will determine the extent of the risk awareness
2. Reporting: The processes have been established. Techniques to effectively capture risk and resolve are commonly accepted by program teams and PMO. The project leaders are also confident of the methodology and the PMO is aware of the risks known to the project teams
3. Value added : The PMO has been well established and is working over a range of projects. Cross functional project experience enables the PMO to foresee risks in the program not self evident to the project teams.
Every organizations leadership wants PMOs to ramp up as fast as possible to Maturity level 3.
Wednesday, March 25, 2009
Sunday, March 22, 2009
I read three things this weekend that got me thinking - (1) Smarter people do think faster , (2)More than 55000 thoughts pass our mind daily and(3) 90+% of the thought is repetitive.
Friday, March 13, 2009
- Plan - Training and competence building + staffing / resource planning for programs (This includes involvement of PMO in strategic planning)
- Do - Support for greater functions and projects
- Check - Metrics and tracking
- Act - Continuous improvement
Tuesday, March 10, 2009
Tuesday, March 3, 2009
Sunday, March 1, 2009
Thursday, February 26, 2009
Sunday, February 22, 2009
Thursday, February 19, 2009
Wednesday, February 18, 2009
The debate between heavyweight vs. light weight PMO is less important than the freedom/authority and reporting given to Program Managers. Often the structure of the PMO is done only to facilitate span of control and less by decision on design of the PMO.
The structuring of projects into logical blocks or programs is an interesting way to control span of control without having a heavyweight PMO (This provides accountability with program managers and also the required span of control). Delivering a KRA definition of Program Managers is critical to success of the organization.
See article from where I picked the picture above for the reference.
Friday, February 13, 2009
- Rapid growth - you have too many things to measure and too many ways for things to go wrong
- Impact of the blackberry gen - You need to give the information as fast as possible for a drill down
- Information overload - too many reporting frameworks means that both executives and staff need things simple
Sunday, February 8, 2009
Saturday, February 7, 2009
Tuesday, February 3, 2009
Wednesday, January 28, 2009
Any process that does not match with intuition (experience based) is discounted as a poor process. Similarly, any new process that does not throw new insights is also discounted as a heavy process for doing something intuitively or from experience. Hence, establishing benefit of a new process is balancing the fine line.
We have also heard common complaints that there is no spirit in the templates and deliverable. People are churning the wheels without the spirit - so what is the "spirit". There are also numerous form vs. content debates
A proposed methodology is
1. Fill the forms/templates/deliverable
2. Check with common sense, get feedback on the content from experts
3. Create a conclusion from the deliverable
4. Highlight issues and closure plans, force learning's from the team (and incorporate in process)
The benefit of the process is only if we can ramp-up learning and standardize across programs to get the benefits of experience standardized.
Every one of these steps must be orchestrated for key programs by the PMO. Hence, while PMO strives for training members on the deliverables, it is crucial to drive debate on the content and signoff on outputs.
Saturday, January 24, 2009
I use a combination of iTunes , iTunes updater and Media Monkey . Use media monkey to update the tags, and iTunes updater to read it into iTunes. I use iTunes since I like the interface to listen to my music.
fIn = open('in.txt','r')
lStr = sStr.split("|")
fN = lStr
id3r = id3reader.Reader(fN)
tr = id3r.getValue('track')
tr = int(tr)
tr = 1
art = id3r.getValue('performer')
tit = id3r.getValue('title')
yr = str(id3r.getValue('year'))
lbl = id3r.getValue('label')
ttltr = id3r.getValue('totaltracks')
ttltr = int(ttltr)
ttltr = 1
id3w = ID3Writer.Writer(fN,tr,lStr,lStr,lStr,yr,lbl,ttltr)
sStr = fIn.readline()
#from tagger import *
fOut = open ("out.txt", 'w')
mp3attribs = ['album','performer','title','genre']
sStr = ""
for roots,dirs,files in os.walk(r'H:\Karthik\Music\Carnatic Music\Ariyakudi'):
for f in files:
fN = os.path.join(roots,f)
id3r = id3reader.Reader(fN)
sStr = sStr + roots+"|"+ f +"|"+fN
while i < len(mp3attribs):
sStr = sStr + "\n"
## i3 = ID3v1(fN)
## print roots,"|",f,"|",i3.album,"|",i3.artist,"|",i3.genre
Thursday, January 22, 2009
Sunday, January 18, 2009
The need for support in a PLM implementation
Typically training for PLM implementations involve users accessing online training material or classes. The real need for training is however, when they start using the system. Any training material placed when keying in details and availability of a person at hand greatly enhances success of PLM implementation.(The latter being the MOST effective)
Some tips when supporting users:
1. Take them from their current system to the new system - what this means? - The support staff need to be trained on the legacy system PLM is replacing. Users will continue to ask you for "How to's" in the context of their current systems
2. Distribute adequate online training material and handouts before training
3. Ensure all process owners are trained atleast once before go-live
4. Provide additional buffer support personell for (a) Retraining users who missed out training (b) enhancements that need to be compleed immedeately after go-live
5. For complex user problems, instruct support staff to say "I dont know" and ask the L2 / L3 support members rather than complicating the situation wherein user has to rework information
My experience with major module go live has been that call logs come down by around a sixth in about 4 months.
The "perfect data migration"
Data migration from any legacy system to PLM involves substantial work especially if the legacy is quite large
Most data migrations suffer loss and inconsistsncy theat can be quite dangerous and often involve substantial rework
The typical sources for data loss are
1. Lack of corresponding attributes (often attributes in relationships)
2. Lack of emphasis at the time of data migration since the history and use of the attribute is not known to several members
3. Incorrect and inconsistent use of attributes in the legacy system leading to problems in splitting and assigning to correct attributes
4. Unstructured information (Textual and pictorial) information in legacy systems
1. My experience is that it is better to migrate the data even if unstructured to reduce reliance on legacy systems.
2. Further converting common reports from legacy systems and attaching to parts/BOMs may also be useful
3. Ensure that all major data migration activities are complete before starting usage and not just the bare minmum to work. Usually, the development team has to work on quick enhancements to support users and hence, time for subsequent data migration is not there.