Transcript What Is WMI

What is MSF V3
And why should I, as a Manager,
Developer, Deployer, Integrator or
Customer, care about it
Gad J. Meir
IDAG Ltd.
[email protected]
Copyright © 2003 by IDAG Ltd. and Gad
J. Meir. All rights reserved. (Some parts
quote Microsoft public materials). This
presentation, its workshops, labs and
related materials may not be distributed
or used in any form or manner without
prior written permission by the author(s).
Copyright © 2003 by IDAG Ltd.
About the Lecturer






Gad J. Meir
[email protected]
IDAG Ltd.
B.Sc in Computer Engineering, Technion Technical Institute of Israel
MCSE, MCSD, MCT and most other Microsoft
Certifications
Certified MSF Trainer ,Microsoft International
Copyright © 2003 by IDAG Ltd.
About IDAG Ltd.









Multi-disciplinary Knowledge Mining and Integration
Knowledge Measurement and Gap Analysis
Knowledge Transfer
Consulting, Mentoring, Troubleshooting
Founded in 1983
Establishment of Microsoft University IL (1992)
Project management mentoring, using Microsoft Solution
Framework (MSF)
Microsoft Solution Provider
At least 25% of company time is dedicated to practical projects
in order to acquire real-world experience
Copyright © 2003 by IDAG Ltd.
…




Why don’t you make mistakes ?
Because I have a lot of experience !
How did you get your experience ?
I did a lot of mistakes !!!
Copyright © 2003 by IDAG Ltd.
Project Failure Rates
Failed
28%
46%
Succeeded
Challenged
26%
Based on Application Development
Projects, but Similar Numbers are in
Deployment and Integration Projects
Copyright © 2003 by IDAG Ltd.
Success Hasn’t Come Easily
2000
1998
Failed
Challenged
Succeeded
23%
49%
28%
28%
1995
1994
46%
40%
31%
26%
33%
53%
27%
16%
This chart depicts the outcome of the 30,000 application projects in large, medium,
and small cross-industry U.S. companies tested by The Standish Group since 1994.
Source: The Standish Group International, Extreme Chaos, The Standish Group
International, Inc., 2000
Copyright © 2003 by IDAG Ltd.
What exactly do you mean by
Challenged ?

Challenged is the nice positive American way to
tell you that you fucked the project





Average cost overrun: 189%
Projects re-started: 94%
Time overrun: 222%
Functionality delivered on average: 61%
The truth is

If a project is delivered on time, within budget and
exactly according to the specifications, it is a
miracle (miracle := 25%)
Copyright © 2003 by IDAG Ltd.
Root Causes of Failure

Separation of goal and function


Separation of business and technology



The development team doesn’t understand the business and
interprets the specification wrong
The process of the project is not clear to the customer and the
team
Failure to communicate and act as a team


The technology should serve the business and not become the
reason for the change
Lack of common language and process


The specification does not describe the real problem that the
customer wants to solve
The team is not a team but a group of individuals pushing to
opposite directions
Processes that are inflexible to change

When a change is needed in the specification, it can’t be done
without actually restarting the project
Copyright © 2003 by IDAG Ltd.
“When projects fail, it’s
rarely technical.”
Jim Johnson, The Standish Group
The problem is not new and the
solutions are not new






Use good methodology, PMI, CRM, BPR, EAI (Google search
returns over 135,000 sites dealing with project management
methodologies all of them promise the crystal ball)
Learn the subject of project management
Be an expert on the subject meters (anything connected to the
project subject)
Learn how to guide and lead people
Learn Politics and Human resource management…
Be a good psychologist, social worker, emphatic…
Copyright © 2003 by IDAG Ltd.
The practical problem of a
project leader







It’s takes a Huge amount of Information and
Knowledge to master and you don’t have time
It’s easy to get lost in the translation of theory to
practice and you don’t have enough experience
You have to make a many decisions under time
pressure and without enough information
Methodology does not help a lot in day to day
practical decisions
You need something light, easy to use, simple, to
show you the way when you are In doubt
You need a Compass
That’s exactly MSF
Copyright © 2003 by IDAG Ltd.

The Methodology is
the map with the
instructions how to
get there
The framework is
the compass that is
always pointing to
the target and show
you the direction
whenever you are
lost
1st Avenue
Orange Street

Plum Street
Framework: Supplementing Methodologies
2nd Avenue
3rd Avenue
4th Avenue
N
Smith River
W
E
S
MSF
Copyright © 2003 by IDAG Ltd.
Origins of MSF
Microsoft
Worldwide
Products
Groups
Microsoft
Information
Technology
Microsoft
Consulting
Services
Concepts
Models
Best Practices
Microsoft
Partners
Best Practices
Principles
Microsoft Solutions Framework
• Development AND Deployment, not just Development
• Microsoft has a lot of experience in successful and failed
projects and there is a lot to learn from them
Copyright © 2003 by IDAG Ltd.
Setting Expectations

NOT



MSF does not solve all your problems
MSF does not guarantee your project’s success
YES



MSF increases your success percentage
MSF tells you VERY early in the project life cycle
that you are going to fail (You can stop the project
before it costs too much)
MSF is easy to learn and implement
Copyright © 2003 by IDAG Ltd.
Setting Expectations II




I am not going to teach all MSF principles
here and now it is a 4 days workshop
I am going to show some of the principles
and describe the logic behind them
MSF is really just common sense pills to
make your project healthier
You don’t have to take it all at once,
sometimes one good idea is enough to
save you when you are alone in the dark
Copyright © 2003 by IDAG Ltd.
MSF Models and Disciplines
Models
Team
Process
Model
Model
Disciplines
Project
Risk
Readiness
Management
Discipline
Management
Discipline
Management
Discipline
Copyright © 2003 by IDAG Ltd.
Where MSF Fits in the IT Life
Cycle
Microsoft Solutions Framework
Microsoft Operations Framework
Copyright © 2003 by IDAG Ltd.
MSF Process Model Is an
Iterative Approach
Functionality
Minimize risks by breaking large projects into multiple
versions
Version 3
Version 2
Version 1
Time
Copyright © 2003 by IDAG Ltd.
Why Versioned Releases









You can’t effectively manage a project if it is longer than 6
months
Most projects are longer then 6 months
By deciding on versioned releases you can decide which subset
of the problem is fitted to the time
The customer must prioritize the features
The customer has something in hand earlier
Mistakes discovered early are cheaper to fix
Establish your credibility
Give you flexibility in case of pressure
 “We can move this feature to the next release”
Enable you to better fit the solution to your precise customer’s
needs
 You respond faster to changes
 The delta between the specification and the real world is smaller
Copyright © 2003 by IDAG Ltd.
Making Project Trade-offs
Features
Copyright © 2003 by IDAG Ltd.
Why use Project Trade-offs?






Because you will have to
It never goes according to plan
Why bury your head in the sand?
Why not discuss it with your customer?
You will have to do it anyway so why wait for
the first crisis
How can we do all this ??? …
Copyright © 2003 by IDAG Ltd.
Project Trade-off Matrix
Help your customer help you
Features
Resources
• Constrain – do not
change, this is a
constant
Schedule
• Optimize – try to
minimize this
Optimize
Constrain
Accept
• Accept – well, I’ll
except any
changes on this
Features
Copyright © 2003 by IDAG Ltd.
MSF Process Model Phases
and Milestones
Deployment
Complete
Release Readiness
Approved
Vision/Scope
Approved
MSF
Project Plans
Approved
Scope
Complete
Copyright © 2003 by IDAG Ltd.
Milestone-Driven Process





Milestones are review and synchronization points,
not freeze points
Milestones enable the team (and customer) to assess
progress and make mid-course corrections
The process model uses two sorts of milestones
 Major milestones, end of logical quarter
 Interim milestones, in the logical quarter
Achieving interim milestone represents team agreement
on position in the process
Achieving a major milestone represents team and
customer agreement on position in the process
Copyright © 2003 by IDAG Ltd.
Milestones are based on
Deliverables
 Deliverables
are physical evidence
(documents)
 Deliverables are signed by the team
(and sometimes the customer)
 A signed (or agreed) deliverable signal
that the team has reached a milestone
Copyright © 2003 by IDAG Ltd.
Different Roles Drive Different
Phases
Milestone
MSF Role Cluster
Vision/scope approved
Product management
Project plans approved
Program management
Scope complete
Development
User experience
Release readiness approved
Testing
Release management
Deployment complete
Release management
Copyright © 2003 by IDAG Ltd.
The process milestones based
Approach
 Segment
the Project into milestones
 Help organize the team
 Facilitate communication in the team
 Facilitate communication with the customer
 YOU NEVER GET BLINDED
 YOU ALWAYS KNOW WHERE YOU ARE
Copyright © 2003 by IDAG Ltd.
Risk Management Model





Risk is a problem waiting to happen
If you don’t analyze it, and prepare for it,
you'll get it in you face
You should anticipate risks, mitigate risks
and prepare contingency plans for risks
Because some of those risks are going to
happen (it is just statistics)
Risk analyzing is integral, living, changing,
part of any project
Copyright © 2003 by IDAG Ltd.
The MSF Risk Management
Process
Analyze and
Prioritize
Risk
Statement
Identity
Control
Risk
Knowledge Base,
Concepts,
and Processes
Learn
Master
Risk List
Top n
Risks
Plan and
Schedule
Track and
Report
The ongoing deliverable of this process
is a living risk assessment document
Copyright © 2003 by IDAG Ltd.
Goals for a Successful Project

Satisfied customers


Delivery within project constraints


Test the code, specification, everything.
Enhanced user performance


Write the code, take development decisions.
Release after addressing all known issues


Watch the budget, deal with crises, mitigate
Delivery to specifications that are based on user requirements


The customer pays you, politics, seals person
Most of the time, the customer doesn’t use the project. It’s the user of the system that
make it a success or failure. (UI design, Graphics, Cognitive approach)
Smooth deployment and ongoing management

Packing, buying equipment, printing, delivering, electricity, water, air conditioning,
logistics, etc’…
Copyright © 2003 by IDAG Ltd.
Understanding the Goals







Overall success requires success in each goal

Any of them may fail the project

It is straight from the root, because of the failure we discussed earlier
Each goal must be equally valued
Each goal requires disciplines that are focused on
that goal
Each goal needs different qualifications
You need them all
You can’t learn everything, you cant do everything,
you cant be everyone…
So….
Copyright © 2003 by IDAG Ltd.
MSF Team Model
Delivering the solution
within project constraints
Satisfied
customers
Program
Management
Product
Management
Building to
specification
Development
Communication
User
Experience
Enhanced user
effectiveness
Test
Release
Management
Approval for release only
after all quality issues are
identified and addressed
Smooth deployment and
ongoing operations
Copyright © 2003 by IDAG Ltd.
Team of Peers






Is a team whose members relate as equals
Has specific roles and responsibilities for each
member
Empowers individuals in their roles
Holds members accountable for the success of their
roles
Drives consensus-based decision-making
Gives all team members a stake in the success of the
project
Copyright © 2003 by IDAG Ltd.
Principles of a Successful
Team






Team of Peers
Shared Product Vision
Product Mindset
Zero-Defect Mindset
Customer-Focused Mindset
Willingness to Learn
Copyright © 2003 by IDAG Ltd.
Scaling for Small Projects
Product
Management
Product
Management
Program
Management
Development
N
N
P
P
U
N
U
U
P
N
N
N
P
P
Testing
Program
Management
N
Development
N
N
Testing
P
U
N
User
Education
P
U
N
P
Logistics
Management
U
P
N
P
Possible
U
P
Unlikely
Copyright © 2003 by IDAG Ltd.
User
Education
Logistics
Management
U
U
N
No
Example: Small Teams
Small team, combined roles
User
Experience
Program
Management
Product
Management
Release
Management
Test
Copyright © 2003 by IDAG Ltd.
Development
Scaling for Large Projects



Divide large teams into smaller teams, which
have
 Lower process overhead
 Lower management overhead
 Lower communication overhead
 Faster implementation
Create feature teams—multidisciplinary
subteams organized around product feature
sets
Create function teams—unidisciplinary
subteams organized by functional roles
Copyright © 2003 by IDAG Ltd.
Feature Teams
Multidisciplinary sub-teams organized around product feature
sets or created to focus on a particular capability
Program
Management
Product
Management
Development
Lead Team
User
Experience
Test
Release
Management
Program
Management
Program
Management
Development
User
Experience
Desktop
Feature
Team
Development
User
Experience
Test
Program
Management
Development
User
Experience
File and Print
Feature
Team
Test
Copyright © 2003 by IDAG Ltd.
Messaging
Feature
Team
Test
Example: Function Team
Group Product
Management
Product
Planning
Evangelism
Product
Management
Public
Relations
Marketing
Copyright © 2003 by IDAG Ltd.
MSF Team Role Clusters and
Their Functional Areas
Program
Management
Business value
Marketing
Customer advocacy
Product planning
Project management
Solution architecture
Process assurance
Administrative services
Product
Management
User
Experience
Technology consulting
Implementation architecture
and design
Application development
Infrastructure development
Development
Test
Accessibility
Internationalization
User advocacy
Training/support material
Usability research and testing
User interface design
Release
Management
Infrastructure
Support
Operations
Logistics
Commercial release
management
Copyright © 2003 by IDAG Ltd.
Test planning
Test engineering
Test reporting
MSF Readiness Discipline
Define
Assess
Evaluate
Change
Knowledge
Skills
Abilities
Copyright © 2003 by IDAG Ltd.
Courses





1846: Microsoft Solutions Framework Essentials
1737: Microsoft Operations Framework Essentials
1585: Gathering and Analyzing Business Requirements
1608: Designing Business Solutions
1609: Designing Data Services and Data Models
 All Syllabuses are available on Microsoft’s web site
Copyright © 2003 by IDAG Ltd.
For More Information
 Web


sites
Microsoft Solutions Framework site at
http://www.microsoft.com/MSF
Steve McConnell’s Survival Guide site at
http://www.construx.com/survivalguide/home.htm
 Books





Dynamics of Software Development, Jim McCarthy
Rapid Development, Steve McConnell
Software Project Survival Guide, Steve McConnell
Debugging the Development Process, Steve Maguire
Microsoft Secrets, Michael A. Cusumano and Richard W.
Selby
Copyright © 2003 by IDAG Ltd.
Call to Action

Have management commitment



Find a Pilot project and assemble a team
Train the team using certified trainer




4 days workshop based on 1846
Use one of the trainers or both as a consultant to mentor the
team


If you need help call me Or Eran Kolber for a 1 hour presentation to
management
Just to verify that you are doing it right
There are a lot of gray areas when you try to do it for the first time
If the project succeeds, this team will be the base to build the
other teams
If the project fails, analyze the cause of failure and decide if you
want to try again

Remember, it is statistics and not a full guarantee
Copyright © 2003 by IDAG Ltd.
Questions?
Copyright © 2003 by IDAG Ltd.
Copyright © 2003 by IDAG Ltd. and Gad
J. Meir. All rights reserved. (Some parts
quote Microsoft public materials). This
presentation, its workshops, labs and
related materials may not be distributed
or used in any form or manner without
prior written permission by the author(s).
Copyright © 2003 by IDAG Ltd.