1.

Managing large, dispersed, culturally diverse project teams

Complexities

Many complex adaptive teams

Human behaviors impossible to predict
Multi-layered, interdependent teams
Geographically dispersed
Culturally diverse
Virtual
Multi-skilled
Dissimilar procedures, practices, and tools
leading to integration issues
Risk management inadequacies and
inconsistencies, leading to unknown events
Integration of interdependent components
produced by different teams

Management Approaches
Adaptive

Establish an experienced core

leadership team

Leverage the power of teams

Build great teams

Use edge-of-chaos management when

innovating and experimenting

Empower agile teams

Instil teams with a culture of discipline

Use virtual teams as a strategic asset

Insist on face-to-face meetings for key

planning and decision-making
Conventional

Insist on face-to-face meetings for key

planning and decision-making

Insist on standard procedures and

tools when appropriate.

Establish a culture of collaboration and

open communication.

1. The basic principles of IT project management

a. Communication (Prakasam error)
b. Knowing exactly what the goals of the project are (deliverables).
c. Thorough planning with measurable achievements (milestones) and possible uncertainties (risks).
d. Monitoring and steering the project's progress on day-to-day basis (chasing). Laissez faire is
doomed to failure.
e. Good project management starts with having the right people in the right roles.
f. Self-confidence is frequently related with success. Success leads to self-confidence, and selfconfidence frequently appears to lead to success.
g. Under-promise, over-deliver.
h. In my experience, IT projects *tend to* suffer more from poor scope development and scope
management than other projects. This leads to scope creep, and associated schedule and financial
impacts. Why? Because the business needs are not able to be identified by *either* the business
owners or the technical project team. That's why the scope creep comes in. At 70%, the deliverables
begin to take recognizable shape, and the business customers start getting shifty, thinking....
'hmmm. THAT's not really what we wanted. Maybe you could just add in these other features? Maybe
THAT would do it.'
i. The bottom line, you need to have both the tech skills and people (soft) skills.
j. I like to think of it as Project Leadership (Shashank) rather than project management (Suresh)
k. Ability to Delegate Tasks (Trust)
l. Cool Under Pressure
m. Problem Solving Skills
n. Time ,Cost, Quality
o. Without getting too wordy, produce a project plan (not just a schedule), baseline the project
schedule, measure progress against plan, have a change control proceudre and execute it, track
delieverables, communicate progress, and manage expectations
2. Proj Mgmt Techniques
a. Linear / Waterfall: Good to use if everything is clear, but in practicality there is hardly any project
where are requirements are clear to the client

b. V model: Nothing but line model, but shown graphically in another way. The V-Model demonstrates
the relationships between each phase of the development life cycle and its associated phase of
testing. The horizontal and vertical axes represents time or project completeness (left-to-right) and
level of abstraction (coarsest-grain abstraction uppermost), respectively.

c. Iterative = RUP: Iterative development slices the deliverable business value (system functionality)
into iterations. In each iteration a slice of functionality is delivered through cross-discipline work,
starting from the model/requirements through to the testing/deployment.
i. Inception identifies project scope, risks, and requirements (functional and non-functional) at a
high level but in enough detail that work can be estimated.
ii. i.e. unlike Linear where you finish all the requirements first before moving into design, in
Iterative, you divide into Verticals like Inception, Elaboration etc. And in each phase u do a
little bit of everything

iii. RUP has three supporting disciplines or horizontals

iv. Three supporting disciplines
1. Environment discipline :
2. Configuration and Change management discipline:
a. Configuration management: Version control
b. Change request management: keeps track of the proposals for change.
c. Status and measurement management: Change requests have states such as
new, logged, approved, assigned and complete. A change request also has
attributes such as root cause, or nature (like defect and enhancement), priority
etc.
3. Project management discipline
d. Agile. It emphasize face-to-face communication over written documents when the team is all in the
same location. When a team works in different locations, they maintain daily contact through
videoconferencing, voice, e-mail, etc. It is pretty much similar to Iterative model with the same
phases and fundas.
i. The difference with other iterative models is:
1. The focus is on getting small units of working code developed n deployed in a 1-4
weeks
2. In agile, the activities are all measured in weeks, rather than in months
3. There is not too much emphasis on documentation, as the sprints are short
4. There are daily status updates
5. Agile emphasizes working software as the primary measure of progress unlike
waterfall for which working software is only in the last phases, and all other phases
are just documents (e.g. BRS, DSTD etc.)
ii. Agile is not favourable in cases when (though this is always debatable in industry standards)
1. Failure at any cost is not an option e.g. Aeroplane engine design, surgical instruments
software
2. For large projects where the documentation of each and every small decision and its
traceability to the design is required. Since Agile does not focuses too much on
documentation, it can be a hurdle later.
3. Distributed development efforts (non-co-located teams), because it requires a very
close coordination between the units.
e. Sprial: It is the clone of Agile. The only difference is that:
i. Iit is more suited for long term, complex and lengthy projects where you need long time to
develop, but cannot wait for 4 years for the first outcome to arrive. So it combines a mix of
Waterfall and Agile.
ii. Each iteration can be 6 months to 2 years long
iii. Like Agile, each phase should bring an working code output: called as Prototype 1, Protype
2 ... etc in this case.
iv. Gaming applications, defence applications normally use Sprial

f.

Another basic difference, as I see it, is that most Spiral models of development still insist on big, upfront design. The emphasis is on knowing as much as you can about how the system will be used;
discovering all the use cases. Once you know these, then you design the system and break it down
into phases that follow an iterative detail-design, implementation, test, refactor-design loop.
XP:

Diff w,r,t Agile include:

i. Requirements are expressed as automated acceptance tests rather than specification
documents.
ii. Requirements are defined incrementally, rather than trying to get them all in advance.
iii. Software developers are usually required to work in pairs.
iv. There is no Big Design Up Front. Most of the design activity takes place on the fly and
incrementally, starting with "the simplest thing that could possibly work" and adding
complexity only when it's required by failing tests. Critics compare this to "debugging a
system into appearance" and fear this will result in more re-design effort than only redesigning when requirements change.
v. A customer representative is attached to the project. This role can become a single-point-offailure for the project, and some people have found it to be a source of stress. Also, there is
the danger of micro-management by a non-technical representative trying to dictate the use
of technical software features and architecture.
vi. Dependence upon all other aspects of XP: "XP is like a ring of poisonous snakes, daisychained together. All it takes is for one of them to wriggle loose, and you've got a very angry,
poisonous snake heading your way."[11]
g. Comparison of types:
Agile software development

Pros

Minimizes feature creep by developing in short intervals resulting in miniature software projects and releasing the product in
mini-increments.

Short iteration may not add enough functionality, leading to significant delays in final iterations. Since Agileemphasizes realCons

time communication (preferably face-to-face), utilizing it is problematic for large multi-team distributed system development.
Agile methods produce very little written documentation and require a significant amount of post-project documentation.

Extreme Programming (XP)

Pros

Lowers the cost of changes through quick spirals of new requirements. Most of the design activity takes place incrementally
and on the fly.

Programmers are required to work in pairs (which may be difficult for some developers). There is no up-front detailed
Cons

design, which could result in more redesign effort in the long run. The business champion attached to the project full time can
potentially become a single point of failure for the project and a major source of stress for the team.

Joint Application Development (JAD)

Pros

Captures the voice of the customer by involving them in the design and development of the application through a series of
collaborative workshops called JAD sessions.

Cons

The client may create an unrealistic product vision and request extensive gold-plating, leading the team to over- or underdevelop functionality.

Lean software development (LD)

Pros

Creation of minimalist solutions (i.e., needs determine technology) and delivering less functionality earlier (as per the
paradigm that 80% today is better than 100% tomorrow).

Cons

Product may lose its competitive edge because of insufficient core functionality and may exhibit poor overall quality.

Rapid Application Development (RAD)

Pros

Cons

Promotes strong collaborative atmosphere and dynamic gathering of requirements. Business owner actively participates
in prototyping, writing test cases and performing unit testing.
Dependency on strong cohesive teams and individual commitment to the project. Decision making relies on thefeature
functionality team and a communal decision-making process with lesser degree of centralized PM andengineering authority.

Scrum

Pros

Improvement in productivity in teams previously paralyzed by heavy process, ability to prioritize work, utilization of
backlog for completing items in a series of short iterations or sprints, daily measured progress and communications.

Reliance on facilitation by a master who may lack the political clout to remove impediments and deliver the sprint goal. Due to
Cons

its reliance on self-organizing teams and the rejection of the traditional centralized "process control", internal power struggles
may paralyze the team.

3.

Re: what are the common estimation techniques followed

Answ Common estimation techniques in software engineering

er include:
# 1 1. Parametric Estimating
2.
3.
4.
5.

Wideband Delphi
Cocomo
SLIM
SEER-SEM Parametric Estimation of Effort, Schedule,
Cost, Risk (based on Brooks Law)
6. Function Point Analysis
7. Proxy Based Estimation (PROBE) (from the Personal
Software Process)
8. The Planning Game (from Extreme Programming)
9. Program Evaluation and Review Technique (PERT)
10.Analysis Effort method
4.

Re: what are the tools available for estimation evaluation

Answ Here with i ahve given some of estimation tools ...
er
1. Tool name : QUEST
#1
It is Excel based estimation tool. Supports COCOMO II
estimating factors, Function Point estimating, and
statistical estimating methods
2. Toll Name : Goldenseal
Small business software to cost estimation and project
management
3 Function Point Modeler
Estimation tool based on Function Point Analysis,
UseCaseModel, Business Object Model and Data Model.
5. Qs: Does FP estimation finds only development effort, or the entire project effort

6.

Develop
mentAgile Iterative model RUP Scrum Spiral model Waterfall model XP V-Mode
models

Mode
ls

OtherAutomotive SPICE CMMI Data model Function model Information model

modelsMetamodeling Object model Systems model View model

Modeling
languageIDEF UML
s
7. V Good:
a. Software Development LifeCycle" is a synonym of "development process" and can be
waterfall, RAD, spiral, RUP, agile, etc... Agile is pretty same as Scrum, For example Scrum
methodology is a agile process Rad is informal name given to agile
b. Traditionally the rapid application development approach involves compromises in usability,
features, and/or execution speed. Agile on the other hand doesn't aim to achieve that. The iterations
aren't prototypes, rather, each iteration introduces changes and/or enhancements into the product
and these are reviewed by all parties involved.

c.
8. Agile Development
9. To me agile developments most important aspects are the following.
a. Tackling the most difficult aspects of the projects head first, in the first little iteration. These are the
things that can be show stoppers and thus need to be not only identified but tackled right up front. If
you are going to fail, for whatever reason, then failing early saves time, money, and resources.
Rather than coming to the end and discovering that thing(s) youve been putting of is actually not
possible and the project is a failure.
b. It enables you to go live with a system and it be production ready even if its only 80% done. At the
end of each and every iteration you have a fully tested and working version of the system. So should
management want to rush it out on the deadline dot and its not 100% finished those parts that are
will work. Sure not all features are implemented, but if they can live with that then thats all good.
c. This point negates the above one to an extent. You have customer involvement at every step and
you have regular involvement, input, and testing from them. This means that any issues not
discovered during requirements gathering, analysis, or design workshops can be incorporated along
the way. Your never gona get everything down 100% which is why with water flow (esp for large
projects) when you had over the baby to the client they could rejected it straight away. Even for the
most fickle reasons such as colours or critical reasons. Having the customer regularly involved also
does some really nice things. It shows that work is actually being done as they have tested it all the
way, they are then put at easy when things do start to go of track and drag on past the initial
deadline. If they understand why, and are kept in the loop then they are more calm and
understanding and realise things and give you more leeway. As opposed to say them not seeng
anything , as in waterflow, and you then asking for more time and money, and know that there will
be more changes to be done anyways. It establishes are good repour and its a two way street which
the developers also need as the input is vital to the success and this is a team effort not client vs
vendor..... You can examine at the end of each time box what happened and plan to tackle un
resoveled issues in the next iteration.

I dont really know what RAD or worked with it, and if i had it was unknowingly so cant really say
too much about it. But really forget the buzz words and stop getting confused between Agile,
Scrum, RAD Prototyping etc as such, pick the one that is best fit for the job.
10.