Making the working group work

You are NOT a PM who has kept up with the times if

• You are not facilitating a working group (WG) with adequate technology, business and QA presence
• The WG is basically a status update call
• Even worse, you don’t have a WG setup!

Some things you can do to setup and facilitate an effective working group are are

Get the "purpose" right

• To provide people the forum to raise obstacles in their path
• Resolve issues needing collaboration with different teams (or take actions to solve offline)
• Share planning information - set expectations on plan
• Make recommendations to the steering committee

Get the right "participation"

• Get Representation from Technology, Business Analysts, Business (Line) and Quality assurance.
• DO NOT let participants forward your invite unless done for delegation.
• Follow-up for lack of participation

Get the "agenda" right

• Move the agenda with project evolution i.e. At the start of the project, use it as a planning forum - use it to get assign actions on defining governance, project communication, project objectives, defining scope, close resourcing etc
• Close on the high level approach to deliver the system (take this to steering for approval)
• When you start to get an handle on the project releases, discuss the high level plan and get buy-in from people
• Move to a SDLC based agenda once the release plan is being tracked. Get in agenda Items to track Requirements, Design, Build, Testing deliverables.
• Have a slot for people to bring-upp issues regarding to the project
• Dedicate atleast 30% of the time to track on actions from previous projects (best done at the start of the meeting)
• During important milestones, use the WG as a checkpoint. Use it to disseminate the information to the stakeholders.
• Before each meeting, ask yourself - What is the biggest issue plaguing the project - Table it for discussion and resolution as a separate agenda item.
• AOB (Any other business)

Get your "position" right

• Ask the right questions, Let people talk
• Representatives should provide an update on behalf of their teams and highlight dependencies on other teams. Your question should be - Is there a dependency you have on getting this done by 16-Jan? or do you think there is a chance we might miss this deadline for the 12th-April-2011, why do you think so?
• Cthe right action and confirm with the action owner during the course of the meeting.
• Be the scrum master, not the task helper.
• Stop the fighting between different teams and present the issue in a progressive sense example – When BA’s and IT disagree, narrow down to the point of disagreement so a resolution can be found. Discourage team positioning against each other
• Get the quiet ones to talk. Example “Hey Bart, we haven’t heard from you on this one…are you happy with it?”

Hope this helps!

Things we easily forget

Peeps, this is a bit of a random post, but one that discusses the items that are easy to ignore. PMing is not a job, its an ownership. Been making post-its for myself of things to engrain in my approach. The mess on my desk has become unbearable, so I am transferring it to this electronic medium!
Friendly & Firm can go together - No one likes a tight arse, dont be one. Break the formality while dealing with business users & put them at ease. Being formal (officious is worse) makes you come across as COLD in your relationships. Relationships salvage projects from tough situations, and without close bonds, you will be handicapped.
Protect the primary objective of the project - Most projects that are undertaken in an end user organization will usually get more than 1 streams of work. In such a situation, identify tehprimary objective and ensure that all decisions regarding scope, budget & delivery protect the primary goal of the project. IMPORTANT!
Retain the ability to Say "No" - Not all the items on the project wishlist can be taken. This trait separates the average PM's fromt he good ones. Say No firmly, but with firmer reasons to backup your argument.
"Plan" content and acceptance, not tool and beauty - This is a bug that infests a lot of PM. There is a lot of focus in getting the plan "finished" and making it "beautiful" rather than focussing on the content and buy-in. Follow 70/30 Spend 70% of the time getting buy-in & content and 30% to make it presentable.
Back your decisions and be seen as a prick vs Succumbing to what stakeholders say - Interesting one this is. But here is what i say. If you believe in something for the right reason, back it up to the hilt. People may not like it, but will recognize teh value later. Everyone likes a well deliverd project. Liking the PM is just an added advantage. Plus if "everyone" likes you, start getting concerned :)
Inheriting a team does not mean you need to retain it - Applicable when you walk in to an existing team. Take time, understand their capabilities , but do NOT be afraid to rejig them around if you believe that it will help the project.

Start the race right!

Often times I've been faced with a situation that needed the project to be up and running ASAP. As project managers, you must have faced this situation all the time. Sometimes, its the sales pitch causing more pressure on delivery, sometimes it is a valid customer driver needing the product out faster. Regardless of the cause, the impact on the project is predictable - you may well get off the blocks faster, but like all marathon runners know- it may actually set you back in the race at the end. Remember that Finishing the race is always more important than starting it. The trick therefore is STARTING THE RACE RIGHT!

In no way is this list exhaustive, and I am the first to admit that I have only learnt from the numerous mistakes I have made! Looking back, here is a synopsis of things I could have done better and things I managed to deliver :). I purposely use a tactical style so you can easily relate it to your projects. The first thing to acknowledge is that there needs to be a plan for setup. However, do not expect it to be sequential. It is unreal to expect that you will get dedicated time to setup a project before it really begins. Reality throws the project at you and you will need to start some form of execution. Don’t worry about this so long as you keep crossing items from your project start-up checklist.

YES I RECOMMEND A START-UP CHECKLIST instead of a sexy project plan for managing the starting phase of the project. The rest of the process pans out much easier if you see it as items to knock off the checklist, rather than a plan/schedule with dependencies.

Function Points

This is my first post on request. Thanks Ashish! As a follow-up to the Estimation Post, i am going to write about a great top down technique to estimate project SIZE called function point analysis. Before we get to the "How" lets know the "Why(s)"

WHY

• Standard benchmark technique across organizations throughout the world - If 2 organization perform an estimate for the same piece of work, their function point counts should be exactly same in a perfect world.


• Technology Independent - Keeps the Technology out of the exercise. Once the size is estimated, different technology effort estimates can be derived using productivity.


• Can be used to monitor scope creep by doing FPA at each phase of project.


• Does not require you to know all the details of the work you are estimating - The goal is to know what you need for the FPA count and that is ILF, EIF, EI , EO, EQ. So long as you can count these, you're good to go. Will talk more about it later.


• Very good for estimating systems with UI interfaces and data storage.


• Take an organization's Actual Results into account to arrive at the effort - Since FPA is a size estimation technique, the Effort estimates are arrived at using a simplistic formula. Effort = # of Function Point / Productivity. Productivity is calculated by looking at the organization's record of executing projects in similar domain (Technology and Business). For example, a company ABC created an application called charlize :) and in the estimation phase estimated it to be 100 Function Points. They delivered the project by consuming an effort of 2000 person hours (overrun, communication, delays everything included) . Then, whenever they do a project similar to charlize (in domain and technology) the productivity they can use is 100/2000= .05 FP/Hr . As the company does more and more projects, the productivity figures become more mature and the organization takes an average figure into account.

Word of Caution

• First Timers -For people or companies using FPA the first time, it is good to do small sample projects and arrive at some baseline productivity figures. Alternatively, there are published figures on the Internet for productivity - Those can give you an indicative guidance. I prefer the former.


• NOT for for creative and non-GUI projects.


• NOT for high complexity logical programming - If you want to design, code a cubing and stacking algorithm for a transport company. FPA might not be the best thing to do.


• NOT For Maintenance projects

Function Points EXPLODED!

STEP 1 - Defining the Application Boundary

The first activity in FPA is defining the Application boundary. This boundary must be drawn according to the user’s point of view. The boundary indicates the border between the project or application being measured and the external applications or user domain. Once the border has been established, components can be classified, ranked and tallied

STEP 2- Finding all 5 Major Components

FPA addresses 2 fundamental types of data in a system.
Data at motion - Data entering or leaving the application boundary. These can be External Inputs, External Queries or External Outputs.

Data at rest - Data maintained by the application. These are the internal logical files in an application. Also, internal logical files maintained by "other" applications outside the application boundary are counted as External Interface Files.
*For examples of each type of component, Click Here.

• Component 1 - External Inputs (EI) - is an elementary process in which data crosses the boundary from outside to inside. This data may come from a data input screen or another application. The data may be used to maintain one or more internal logical files. The data can be either control information or business information. If the data is control information it does not have to update an internal logical file. The graphic represents a simple EI that updates 2 ILF's (FTR's).


• Component 2 -External Outputs (EO) - an elementary process in which derived data passes across the boundary from inside to outside. Additionally, an EO may update an ILF. The data creates reports or output files sent to other applications. These reports and files are created from one or more internal logical files and external interface file. The following graphic represents on EO with 2 FTR's there is derived information (green) that has been derived from the ILF's


• Component 3 - External Inquiry (EQ) - an elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files. The input process does not update any Internal Logical Files, and the output side does not contain derived data. The graphic below represents an EQ with two ILF's and no derived data.


• Component 4 - Internal Logical Files (ILF’s) - a user identifiable group of logically related data that resides entirely within the applications boundary and is maintained through external inputs.


• Component 5 - External Interface Files (EIF’s) - a user identifiable group of logically related data that is used for reference purposes only. The data resides entirely outside the application and is maintained by another application. The external interface file is an internal logical file for another application.

Step 3 - Rating all Components as Low , Medium & High
After the components have been classified as one of the five major components (EI’s, EO’s, EQ’s, ILF’s or EIF’s), a ranking of low, average or high is assigned. The classification of the components is purely based on How many DETs and RETs/FTRs you count for each component.
For transactions (EI’s, EO’s, EQ’s) the ranking is based upon the number of files updated or referenced (FTR’s) and the number of data element types (DET’s).

For both ILF’s and EIF’s files the ranking is based upon record element types (RET’s) and data element types (DET’s). A record element type is a user recognizable subgroup of data elements within an ILF or EIF. A data element type is a unique user recognizable, non recursive, field.
Based on the counts, a complexity and therefor a number is associated with each component. Have a look at the attached tables

I KNOW THIS IS CRYPTIC - JUST DIGEST THIS AND IN MY NEXT POST, I WILL HOST A REAL LIFE EXAMPLE WITH ALL THESE FIGURES EXPLAINED.

Step 4 - Computing the Counts (Unadjusted)
The counts for each level of complexity for each type of component can be entered into a table such as the following one. Each count is multiplied by the numerical rating shown to determine the rated value. The rated values on each row are summed across the table, giving a total value for each type of component. These totals are then summed across the table, giving a total value for each type of component. These totals are then summed up to arrive at the Total Number of Unadjusted Function Points.

In this case the TOTAL is 62 (Click on Image for full view of table)

Step 5- Calculate the Value adjustment Factor (VAF) and Adjusted Function Points
To arrive at Adjusted function points, the VAF is derived so that you can apply the following formula

Adjusted Function Points = Undjusted Function Points* VAF

The value adjustment factor (VAF) is based on 14 general system characteristics (GSC's) that rate the general functionality of the application being counted. Each characteristic has associated descriptions that help determine the degrees of influence of the characteristics. The degrees of influence range on a scale of zero to five, from no influence to strong influence. This is where your experience comes into play and you can impact your function point count based on your understanding of the application and it's general characteristics.

In this case the VSF comes to be 1.24

Therefore our Adjusted Function Points = 1.24*62 = 76.88!!!!

Step 6 - Calculate the Effort
Lets assume that the productivity is .125 function points/Hr

Therefore, Actual Effort = 76.88/.125 = 615 Hours

Promise - NEXT POST WILL BE AN ACTUAL CASE STUDY SAMPLE!

Planning your Estimation

A project can succeed or fail for a variety of very well documented reasons. I want to touch upon one reason i think impacts projects before anything else does -Estimates! Rather than write on detail on "How to Estimate" (Plan-Do-Check-Close is always a good philosophy), I want to share some tips that are helpful

• Make sure you understand the scope - The way i like to look at this is - Can you describe the scope in a short paragraph without the use of a "But" or "If" or an assumption?If you cant, there is a good chance your estimates will be incorrect.
• Estimates are best done in iterations-There is no such thing as getting an estimate right the first time you do it. A good estimate is arrived at by setting a base line and fine tuning it to a place where it provides maximum comfort to all stakeholders. Bad corollary but effective - An estimate is like a chef cooking curry, keep tasting it to where it seems just right. :)
• Estimate (Total) = Estimate (Core Work) + Estimate (Non Core work). Meetings, Mail Checks, Reviews, Communication, documentation and many more are non Core Work. Remember the formula and use it as a philosophy. A good figure to go by is that generally 80% of estimate should be core work.
• Know your Buffers - Risk Buffers, Expected Slippage Buffer , Scope Creeps , Expected delays, Uncertainity all need to get factored here. What these figures need to be? Get an experienced hand to guide you and go by gut feel.
• Budget enough time for estimation - one ballpark i like to use myself is - 50% core estimation work vs 50% review and re-work on the estimates. At times you do not have the luxury of so much time. The ballpark still holds - find time for a review.
• Have specialists for their role - ie an Architect, a developer, a tester to take care of their items. No substitute or tip here. Must do activity.
• Technique - While choosing the technique to do your estimation, try and choose 2 techniques and run them parallelly. In an ideal case , 1 should be a bottom up approach and the other should be a top down. Arriving at independent figures will give you 2 perspectives and if the 2 dont align well with each other, you know something is broke. If time and expertise dictates that you are not able to use formalized techniques like wide band delphi , function point analysis then use your home grown wbs but still do the validation between bottom-up and top-down. You'll be glad you do this.
• Another biggie is to tune the estimates according to a high level plan. Mostly i have seen the estimate to be fixed and the plan is created to match the estimate. This exercises is dangerous as it can over commit on delivery expectations. Good planners will create an estimate and a plan and start iterating (Modifying) on either to achieve the right balance. Balancing a plan, schedule and estimates is a key exercise in estimation.
• In your review setup, you need to have some distinct type of people. They are - People who have executed similar work themselves , People who are probable to execute the project when it comes to you and People who prepared the estimates. Split up the review into 2 parts - Firstly, Validating the estimation exercise from an "technical" perspective and secondly, validating whether the scope of estimate coverage includes items like project risks, activities that are non functional in nature.
• For the review, be prepared to create a pivot chart your estimates. This will give enough flexibility to the reviewers to slice and dice the estimates to review it properly according to their experience. They can utilize it to look at phase wise distribution amongst many other things. This pivot can also be useful at the planning stage. look at this example

Key Figures removed for IPR protection.

Salute Tiger Woods

Tiger Woods' 24-footer for birdie knocked out Bart Bryant for his 64th PGA TOUR win. The win keeps alive "A perfect season" dream as he has won in all 5 starts in 2008. I salute the king!

Tiger Thoughts

• Yes, perfection can be improved.
• There is no way you get what you want to without doing what you need to.
• Parents play a great role in shaping a child's future.
• At All times, you and only you yourself know what is best for you.
• Being of color is not an excuse, it is a privelege.

Dr. Fixit

A troubled project needs help. Your boss expects that you can make a positive impact and asks you to be the "Bridge over troubled waters". You go back to your desk and say wtf, I'm screwed. Calm down, have a decaf and take a leaf out of the a Doctors book.
Forget the project management jargon for a minute and wear your doctors hat! Some of your guiding principles revolve around how Mr. Doctor operates

Diagnosis
Study the project and gather all the information you require to identify all the problems. Get as much detail as possible for symptoms, causes and effects . Once done, you have a fair idea of the project and your diagnosis is accurate and prioritized!

Discuss
Doctors also rely on books and their colleagues to discuss peculiar cases and confirm the diagnosis. Go ahead and do this step in your projects too. Trust me, You'll be glad you did.

Prescribe
Doctors look at best medicines, affordability, any substitutes , side effects and supplements. You need to do the same. Look at the best action items and tailor them to the project. Identify any other areas that might break due to the action items that you are going to take and plan pro actively!

Monitor & Adapt
A follow-up visit is where progress can be checked and an alternate course of action can be decided (if required). Any small changes in medication (Action Items) can be done too.

The idea is have basic framework for fixing troubled projects and work around it. It will lead you to be an efficient Dr. Fixit!

Philosophy and Reality

Philisophy
Lets assume all you guys believe in God. I dont mean the super natural or a higher power but a God as in a God! You know, the kind Jim Carey was for 1 day in that movie... Yeah you get my drift now! Now that you are a believer, it follows that you also believe that "God" watches over the entire world and manages everything. Everything we know, everything we see, hear and pretty much everything that we dont even care for!

Reality
We know that a lot of things are absolutely broke in the world right? Darfur, University Shootings, Africa famine and Starvation, Crime against Women in India, Amount of Terrorist Organizations, Climate Change , War and Poverty! So we stay in a place where everything is bad and there is no good. True? False? I'll leave the answer to your interpretation but here is what i think.

It is obvious that a lot of things are going well too. For instance, we all grew up or was that supposed to be a given? The world has developed so much that information is accessible at the press of a finger? The world has become smaller, we're all traveling and seeing places we'd only read about. Even Doordarshan is improving. India has changed, we are a developing economy now and developing fast at that. We will host common wealth games soon, we'll have a Nano car even sooner.

I guess someone is doing a darn good job somewhere!

Bottomline(s)

• In the work we all do, there is more good than bad. So give yourself a pat on the back for doing what you are...you deserve it.
• We tend to focus on the bad and take the good as granted.
• If it works for God, it definitely works for us:)

Mind the Gap!

Hi! This post has been a long while coming but i changed jobs and so i took me a while to get it out of the blocks. I have taken up working for Sapient and have liked the agility here. For the other offshore players, that are big and not as agile, i believe the market is right for niche consulting companies to come in and bridge the widening gap between the company and the customer.

Here is what I am thinking on a high level.

• It can be a group of senior people (PMPs, Technology Managers) who can come together and offer Risk Management and Strategy Planning for Software Projects done from offshore. It will be a consulting company.
• The consulting company will offer services to the customers outside India.
• They should identify risks/mitigations at each level of the engagement/project. For first time outsourcers, there are things that they do not expect. So at the initiation stage, the consultants can play a key role in identifying and mitigating all the risks that are possible.
• One of the main issues in offshore/onsite engagements is the gap between the customer and the outsourcing vendor. I think that by acting as representatives of the customer, `this gap is reduced, be it in planning, objectives , communication or requirements.
• By being representatives of the customer, a neutral and fair view will be achieved. For example, informing the customer on a fixed frequency basis of all the planning and strategic issues and their possible mitigations. This will ensure that issues are caught early in the life cycle and a corrective action will benefit everyone.
• Expectations Management - The project balancer will be able to manage the expectations of the client by keeping the client informed of outsourcing +ves as well as -ves. In some cases, this will involve helping the client deciding on the offshoring strategy or even evaluating whether outsourcing will be a good option for specific projects or not.
• Setting the Right communication plan - Most offshore projects are troubled for this cause. We do believe that there are significant benefits of creating a strong communication network.
• Avoiding Latency - By being present here in India, they can lend agility to the process.

Here are some specific questions i would like to ask you

1. Firstly, how receptive are you to this ?
2. How much you think companies that are outsourcing already will be ready to pay for this service?
3. What are the challenges that you see for this to be successful?

Leave me a comment and we can have a chat about it.

The Year of Self Development and NANO!

Finally Enlightened. This year is the year of self development and following your dreams.

I think its the nano that has inspired me. http://www.tatapeoplescar.com/tatamotors/

In the meantime, I am working on this concept centered around Risk Management of "Outsourced" Software Projects. Have a feeling I am on to something here.....NO It wont be as good as the NANO!

Team Management by a Cricket Captain!

In my first experience with management I always thought of how my mentors could give me a real life perspective on management. As i have gained territory, i have seen many a case study in management to learn from and appreciate. Some very interesting examples are - The multi-tasking so called "domestic" wife, The mumbai Dabbawalas, The very organized Eunuch community in India and ofcourse the big one - The captain of a Cricket Team! In this post I attempt to bring management to a common platform using a cricket captain.

Lets see if we can learn some important lessons from the captain!

1. A good team makes a good manager great! All Australian captains in last 15 years have benefited because they're team has backed them up. Compare the same to an Inzamam or Lara who tried to get the best out their teams and perhaps they did, but results eluded them due to quality.
2. A good manager finds the right balance in the team. The team composition is decided by looking at the pitch, conditions and form of the players. Same applies to projects, finding the right resources/skill set according to project requirement is an essential ingredient for success. One size never fits all.
3. The master Tactician- A good reason why Saurav Ganguly did so well against a visiting Australian side was that he got inside their flesh with minor irritants. Apparently, he made Steve Waugh wait for each and every toss in all the test matches. This ensured that he was calling the shots even before the match started. In the same vein, he also realized that the by being a part of the youngsters ensured that they felt wanted and valued. This enthused the youngsters and brought him great results. Similarly, managers need to use tact by seeing what will motivate their team members and what will trouble the project irritants.
4. The manager always needs a counsel! Waugh-GilChrist-Warne, Saurav-Sachin-Rahul. What is the reason you see such groups coming together very often in a game and discussing the situation and strategy? The final decision is up to the manager, but to build consensus and use the experience in the team to make the correct decision is tough. This is what differentiates between good and average captains.
5. Leadership - Leading from the front. Absorbing all the pressure rather than transferring it to the team. In this regard Imran Khan was an absolute role model for entire Pakistan team and his leadership inspired players to success beyond their abilities. Such is the leadership that managers should bring to the table - be a role model and be inspirational.
6. The manager needs to still keep performing on his own tasks! Saurav Ganguly exited the captaincy when he wasn't scoring runs, so did Sachin and recently Rahul. The essential aspect is that for the team to trust and believe in you, they need to see results and that applies to all managers and captains!
7. Praise your team for good results generously and openly. Be firm for poor results/actions, but indoors please! Please please please do not rant in public. Its too noisy and definitely demotivating. I dont like Ponting but he's a good example here.
8. The most skilled is NOT necessarily the best manager. Case in point - Sachin! The best player by far but doesn't have an envious record as captain.
9. Once everything is done and results are acheived, Take out your short and go crazy on the balcony at Lords:)

Strategic Partner Selection - A Rude Awakening!

Working in a startup has its own challenges. We pride ourselves on trying to create a solution that is not yet out there in the market. The great thrill is to see who crosses the finish line first, specially now with some competitors coming. Time to market being critical, we invited a company to help us build some of our components as our team was busy and here is what happened!

For the first time, I was on the customer side of the outsourcing relationship! We were thrown a bunch of people in a pre-sales pitch. The partner team was more interested in knowing how many people will they be able to make billable rather than knowing what work needed to be done. We had a day long meeting of sharing facts with them and deciding where they could bring value.

We wait for a week and they get in touch with us and propose that they should do everything for us (instead of our own technology team!). They disregard their positioning and their depth, but they propose that the partner will cure all the troubles with Scrum! I guess there are some folks who still think that Technology and Agile Management drives business/domain rather than otherwise! Needless to say, we disregarded their advice, but the following best practices emerged

1. Always do references check with an existing customer of the company. A call is a must if meeting them is not an option.
2. Choosing a partner must bring in domain knowledge of your own domain.In our case, this was health care!
3. Try and ensure that you can ensure that you meet your team on your projects. - A Hard Sell, but very very important.
4. PILOTS are the right and only way! Constraints of Time, Cost and Scope are ever present, but if you are the manager, ensure that you give the partner a project with low priority but above average difficulty to gauge the team.
5. For managers risk identification and mitigation is everything right? So do a map of strengths and weakness of the partner and once the relationship is established, do appropriate work allocation.

First Post - Happy New Year!

I have resisted the urge to blog for a couple of years as I thought i didn't have much to say. Finally, I am starting this blog with the intent to pen down all advice I have managed to accumulate over the years! - BOTH solicited and otherwise:) I'm a Tech-Guy so my posts will have a liberal sprinkling of technology stuff but am sure to put out a few lighter ones too:)
I hope the year gone by will be cherished forever and wish you all a very happy 2008!