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!

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.

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!

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.