2. Agenda
• Parks Reservation Service Project
- The client
- The challenge
- The project
- The solution
- The results
• Lean Software Development
- Principles and Practices
- How Project Management and Project Leadership are different
• Lean Software Development Tools and Techniques
• Declaration of Interdependence
- Project Manager Declaration of Interdependence
• Is my client ready?
• Questions?
4. Park Reservation Service – The client
• Manitoba Conservation is comprised of 4 divisions as
follows:
- Regional Operations – delivers departmental programs on a
regional basis (park and campground operations)
- Programs – provides the policy direction and systems support for
program thrusts of department (parks)
- Environmental Stewardship – legislation, policies, plans, and
programs to sustainably manage resources and the environment
(Exec Sponsor for PRS)
- Corporate Services – management of cross division services
such as human resources, financial, computer and
administrative support (IT support and financial management
for PRS)
5. Park Reservation Service – The client
• Dimensions of Parks and Campgrounds
- 57 Campgrounds
- About 5,500 campsites
- 11 Campgrounds currently computerized
• Bakers Narrows, Big Whiteshell, Birds Hill, Falcon Beach, Falcon Lakeshore,
Grand Beach, Gull Harbour, Kiche Manitou, Otter Falls, St. Malo and West
Hawk
7. Park Reservation Service – The challenge
• Government committed to have a “ made in Manitoba
solution “ for Spring 2006.
• The RFP was released in early December with a closing
date of Mid-December.
• Protegra proposed a consortium approach to deliver the
solution by the opening day of April 3rd.
• Protegra was awarded the contract in early January
2006.
8. Park Reservation Service – The challenge
• Challenges faced:
- Time line
- Client new to Protegra, Protegra new to provincial government
- Consortium approach – time and complexity
- Complex Government Environment
9. Park Reservation Service – The challenge
Protegra Function Four IDFusion ManLab Nextechnologies
Project Management Office Project Executive Project Sponsors
Cheryl Hedley
Wadood
Terry Bunio Protegra
Ibrahim
Protegra Serge
Protegra
Scrafield
GOM
Dan Haughey David John Clarkson
GOM Primmer GOM
GOM
Service
Conservation STEM Finance Communications
Manitoba
EDS Dimark IBM MTS Key Crow Moneris
10. Park Reservation Service – The consortium
• To address the timelines and challenges a consortium
approach was created. The consortium involved the
following companies
- Function Four – GIS Technology and Training Expertise
- ManLab – Government of Manitoba Graphics Experience
- IDFusion – long time development partner of Protegra’s
- NexTechnologies – Domain Expert in Reservations
• This offered the team a unique balance of expertise, but
also had the following implications
- More time was spent early on in contract negotiations and
teaming agreements
- More time was spent determining how to communicate, report
and work well together
11. Park Reservation Service – The project
• The Parks Reservation System (PRS) was developed in
2006 to replace the existing campground reservation.
• Scope included:
- Self-initiated reservations over the Internet,
- Campground attendants to make reservations on behalf of
clients, and;
- Call centre employees to make reservations on behalf of
campers.
12. Park Reservation Service – The project
• Project details
- Project team included over 20 developers at maximum
- First Phase was delivered in 3 months, On Time!
- Included investigation and integration of GIS mapping
technology
- Phase 1 alone was over 7,400 hours of development work, all
three Phases were over 12,000 hours.
- Quality of the application has exceeded industry standards with
only a few defects since go live
- Project had to achieve PCI certification to go live. PRS was first
of government applications to pass on the first test.
13. Parks Reservation Service – The solution
Welcome
Campsite
Vacancy
No public
authentication required Facility Search Login
Authenticated Users only
Shopping Cart
Reservation
Maintenance Account
Reports
Payment and Campground
Refunds Management
Inventory
Management
Legend:
A very common process flow Checkin Policy
Configuration
A common process flow
Public and Admin functional area
Exchange Rate
Admin only functional area SQL Updates
Maintenance
14. Parks Reservation Service – The solution
PRS Public Web Client PRS Services
Internet · View Campground and Campsite details Public and Admin Services
· Create & Update Accounts · Security service
· Make & Change Reservations · Campground and Campsite service
Public Users · Image service
· View Campground Vacancy
HTTP · Campsite Search service
S
Protegra Client Frameworks · Account service
· Account Search service
· Reservation service
· Transaction service
HT
· Subscription service
TP
Admin Only Services
S
· Inventory Management service
Moneris · Campground Management service
Internet · ePayments and eRefunds · Reporting service
· Reservation History service
· Admin Utilities service
Call Center
PS
· Inventory Sales service
HTT
Staff · User Management service
· Account Alert service
· Daily Arrival Fax service
Intranet · Moneris Reconciliation service
S
PRS Admin Web Client
TP
· Campground Mapping service
HT
· View Campground and Campsite details · Inventory Report caching service
· Create, Find, Update & Manage Accounts · Moneris Refund service
· Make, Find, Change & Manage · Cheque Refund service
Reservations
· View Reservation History Protegra Server Frameworks
· Manage Campgrounds
· Update Campground Inventory & Maps
· Policy Configuration
· Administrative, Inventory and Finance
Reports SQL Server • Parks Database
Parks Staff • Security Database
· Vehicle Permit Inventory and Sales Database
· Refund Management • Resource Database
Campground • Log Database
Protegra Client Frameworks • Reporting Services
Attendants
16. Parks Reservation Service – The solution
- Phase 1 – Public and Call Centre Focus
• Duration: 3 months.
• Functionality focused primarily on the reservation process and
reservation maintenance (i.e. making reservations, changes,
cancellation, payment, refund, etc.)
- Phase 2 – Campground focused
• Duration: 1 month.
• Focused on management of campgrounds (i.e. check campers in,
check campers out, move campers, camping permits, revenue
reconciliation, etc.)
- Phase 3 – Admin site enhancements
• Duration: 7 months.
• Focused primarily on providing more back office support to Parks head
office users
- Phase 4 – Application Maintenance Services
• Duration: Ongoing
• Provided additional functionality for public users, call centre employees,
and campground and head office staff.
17. Parks Reservation Service – The results
• Reservation Counts (Opening day to April 30)
2005 2006 2007 2008
Web 7166 7818 10794 13452
Call Centre 3976 3925 4246 3705
Total 11142 11743 15040 17157
16000
14000
12000
10000
8000
6000
4000
2000
Web
0
2005 2006 2007 2008
18. Park Reservation Service – The results
• Benefits Realized from Lean Development Process
- Client decision maker on site is key to a Lean project.
- Liaise with the clients as much as possible
- Empowering the development team was crucial.
- Traceability of requirements is key with formal organizations
- The team succeeded because they trusted one another
• Potential Improvements
- Quality could be further improved with the use of TDD,
automated test and build tools
- Form in sub-teams of 6-8 to maximize efficiency. Assign a Client
decision maker to each one of these sub teams.
- Leverage Visual Project Management to an even greater extent
19. Park Reservation Service – The results
• The project was awarded the PMI project of the year
(Manitoba Chapter) for 2006
20. Process Notes
• Before even bidding a meeting was held with the project
team to ensure agreement in approach and commitment
to the project and approach
- Everyone knew this would not be an easy project
- Everyone was committed to the challenge and to success
- If we did not have consensus we would have not bid
22. Lean Software Development - Principles
• Traditional Project Management implies:
- Serialization of Project Phases
- Significant focus is on protection of scope
- Many handoffs between different phases and departments.
Many documents are produced because of these handoffs.
- Delivery of working code sometime waits until just before
UAT
23. Lean Software Development - Principles
• Lean Software development emphasizes customer
satisfaction through continuous delivery of functional
software, unlike traditional methods, lean developers
liaise daily/continuously with business clients.
• Deliver working software as frequently as every two
weeks during a project, and encourage changes to the
requirements in response to evolving business needs
• The most crucial aspect is the execution of the project in
iterations which enable quick feedback loops. NOTE:
The iterations apply to the following tasks:
- Project Management and Planning
- Analysis
- Technical Design
- Testing
- Deployment
24. Lean Software Development - Principles
• Iteration planning is the key planning initiative. Iterations
need to be planned in conjunction with the client to
accomplish the following:
- Deliver functionality to define the tempo of the project
- Deliver functionality to deliver real value to the client (working
code)
- Deliver functionality to minimize risk for the entire project
- Lessons learned from one iteration must feed into subsequent
iterations so that we don’t (just) execute the project in iterations
with similar results, but that we execute the project in iterations
with better results.
• The project team executes better, smarter, and quicker
• The project team goes through the process of forming, storming, and
performing
26. Lean Software Development -
Principles
• Most deliverables are enhanced in every iteration
• Every iteration uncovers new opportunities for
improvement and learning
• Opportunities for improvement are evaluated at the
end of each phase and incorporated into the tool and
documentation
30. Lean Software Development - Practices
• Requirements for a Lean Software Development Project
- Define Vision before iterations start. Defining the vision can be
iteration 0.
- Defined iteration length
- High Feedback loops
• Client representative on site and working with the team
• Client representative empowered to make decisions
• Daily project team meetings
- Visual Project Management
- Frequent Builds
- Test Case Driven Development and Documentation. (May be
TDD)
- Refocus requirement discussions on how not what
31. Lean Software Development - Practices
• Refocus requirements discussion on how not what
- Waterfall (Point based)
• Document the scope or the what before we start
• Use the scope document to manage change control
• Discussions on new and modified scope can be difficult as these
requests usually occur later in the project and require additional budget
and schedule. Changes are avoided for these reasons.
• Discussions become adversarial
- Lean (Set based)
• Document the process on how we will define the scope and make
decisions. Define at a high level what you need and how you will refine
it.
• Use the process agreement to manage change control
• Joint Collaborative discussions on new and modified scope and how we
can manage them in the project. Because we deliver in iterations,
changes can be specified earlier and can often be accommodated
without additional budget and schedule. Changes are welcomed.
32. Lean Software Development - How
Project Management is different
• Lean Software Waterfall Project Lean Project
Management Skills Management Skills
Development Project
Manager Detail oriented Adaptable, encourages
change
Characteristics Manages at a lower level Comfortable with ambiguity
- Traditional Project Management
manages the known, Lean or Agile Resistant to change Able to delegate
Project Management manages the
unknown Controlling Trust or faith in team mates
- There are distinctly different ways
how you manage the unknown Company Focus Client Focus
versus the known
Transaction Manager Relationship Manager
- There are distinctly different people
and styles that are more suited to
managing the unknown versus the Manages Scope, schedule, Manages Value
budget
known
Temperment: Guardian Temperment: Idealist
33. Lean Software Development - How Project
Management is different
• Idealist
- These are big picture people who lead followers to pursue
great dreams. They thrive on people issues and gravitate
toward the soft skills: conflict resolution, negotiation, team
building, facilitating. Diplomacy and strategy are their
strong suits
• Guardian
- People with this dominant temperament like to play by the
rules. These are the stabilizers in the organization, working
to keep the boat on an even keel. Meeting budgets and
deadlines and following the plan are important to
Guardians.
Keirsey, D. Please Understand Me II. Del Mar, Calif: Prometheus Nemesis Book Company, 1998
34. Lean Software Development - How Project
Management is different
• In waterfall projects you focus on managing people and
tasks, in Lean projects you focus on leading the process
- Facilitate decision making versus making the decisions
• Project Managers and Project Leaders need to not solve
problems for the team
- Counter-intuitive
- The team will own the problem more if they own the solution
- This is essential for the team to self organize
36. Lean Software Development - How Project
Leadership is different
• Project Manager and Client Project Manager must work
even more closely together than a waterfall project
- Both must focus on the long term relationship
- Both must trust each other
- Both must encourage their companies to focus on value and the
long term relationship
- Both must define a common understanding together for
• Escalation
• Change Request Process
• Issue Tracking
• Reporting
• Formal versus Informal policies and procedures
38. Lean Software Development Tools
and Techniques
• How do we manage scope and change in an
agile project?
• There is no question we will deliver more value,
but how do we provide the visibility the clients
need?
• A lot of the sources out there talk about looser
project management with unconfirmed budget
and scope. How can you ever get a project
approved?
- Don’t provide estimates until after 1-2 iterations
- Execute the iterations until the budget is exhausted
- Keep on adding scope as the project executes by
trading other items
39. Protegra Givens:
• We are a consulting company, some of the luxuries like
not estimating the full project are not options for
Protegra.
- We need to estimate the project for the clients
• We need to inform the clients of changes. Sometimes
Agile proponents advocate change, but we need a
process to ensure the change is communicated and
approved.
- Some times the change is recorded and implied that there are
less formal processes
40. Waterfall
• Provide an estimate for the entire project
• Take a significant amount of time and sign off
detailed estimates
• Execute to that plan. Change request anything to
that plan.
• Scope trading usually not an option. Client not
usually given option to remove items as it
complicates matters
• Objectives:
- Minimize surprises
- Minimize changes
- Maximize predictability
41. Lean or Agile
• Provide an estimate for the entire project
• Take a material amount of time and produce solution and
high level estimates
• Refines estimates as iterations proceed
• Execute to the iterations. Change request anything that
cannot be accommodated.
• Objectives:
- Maximize Value
- Encourage Change
42. Questions
• What is a CR and what is refinement? How should we
account for this time?
• How do you balance Agile and change control?
• What is a scope enhancement? How can we make them
defendable?
• What is an issue? How do you resolves issues and
changes with agile practices.
43. Fundamental Issues
1. Trading Requirements and Refinement of
Requirements can lead to more changes
- Hard to defend as to whether it is a change. Sometime
you don’t know all the assumptions you need to make
and now you have more change!!!
2. Focus on Agility leads project to sometimes
accept more change
- Want to encourage a win-win environment. Don’t want
to make it adversarial right away
3. Agility sometimes leads clients to not give
requirements the attention they deserve early on
- They know they can change it later if they don’t get it
right.
44. Management – Before and During
• Before- Client Expectation Setting
- Meet with Client and determine proper SDLC
• 3 options - Lean, Iterative Development, Waterfall
• Honest discussion of what value is expected
• During-There are two types of scope creep
- New or modified scope items that are easily defendable
(NEW)
• Two types:
- Ones that are identified and documented by the team
- Ones that are just absorbed by the team
- New of modified scope items which are not easily
defendable (MORE)
• They are just MORE
- More complex, More work, More involved
45. Management – Leading Indicators
• Leading Indicators- We need to track proactively
- Burn down charts overall
- EPI – Estimate Performance Index
- Time Entry - ETC
45
46. During Best Practices
• Scope Creep – New Guidelines
- All items added to or removed from the Product Backlog need to
have a change request generated and approved. No exceptions.
• User story name template – US ###.Date
• All stories need to be estimated
• Confirm all estimates with clients before start on Iteration
- This gets buy-in on the level of estimates.
47. During Best Practices
• Scope Creep – More Guidelines
- Bucket that we propose and agree to manage jointly where
estimates are not sufficient.
- Details
• CRs will still occur for obvious scope changes
• To be used for interpretation issues or more issues
• Can be used to manage scope when level of complexity changes
• Requires trust. This may not be possible on some initial engagements
48. Leading Indicators Guidelines
• On the weekly status report, the following leading
indicators will be reported:
- Estimate Performance Index = hours on schedule/hours
actually spent
- Overtime Performance Index = Overtime hours/normal
hours
• This is in additional to the weekly status report of
budget, hours and general progress
- These items above are meant to track the specific type
of scope baby crawl that occur in some agile projects
- I call it baby crawl because it is cute at the start
because it shows customer interaction and
engagement. But unless you set up the gates by the
stairs, scope can get away on you!
49. Leading Graphical Indicator
• Leading Graphical Indicator will be a burn up
chart
180
160
140
120
100
80 features complete
60 features in scope
40 budget
20
0
50. Burn up chart
• Unlike a burn down chart which doesn’t refer to budget,
the burn up chart refers to budget and scope
• This gives constant feedback on the amount of work
required to finish the project
54. Declaration of Interdependence
• At the 2004 Agile Development Conference, a number of
project, product, and management experts started
working together to answer the question "How would you
extend the Manifesto for Agile Software Development to
non-software products, project management, and
management in general?" Their answer is a document
called "The Declaration of Interdependence."
56. Continuous Flow of Value
• WE INCREASE RETURN ON INVESTMENT BY
MAKING CONTINUOUS FLOW OF VALUE OUR
FOCUS
- Unlike traditional waterfall we are managing to the continuous
flow of value, not to what was signed off.
- This may result in delivering something totally different, but of
more value to the client at no additional cost.
- focus on "flow of value" (e.g., not "tracking effort")
57. Joint Ownership
• WE DELIVER RELIABLE RESULTS BY ENGAGING
CUSTOMERS IN FREQUENT INTERACTIONS AND
SHARED OWNERSHIP
- The key is frequent interaction and shared ownership.
- We are a team solving the business problem.
- engage customers in frequent interactions
58. Embrace Change
• WE EXPECT UNCERTAINTY AND MANAGE IT
THROUGH ITERATIONS, ANTICIPATION, AND
ADAPTATION
- We embrace change and encourage it as it adds more value for
the client
- This also integrates highly with the Risk Management Strategy
• Do the riskier items earlier to allow for reaction time
- We do this by iterations, iterations, iterations….
59. People
• WE UNLEASH CREATIVITY AND INNOVATION BY
RECOGNIZING THAT INDIVIDUALS ARE THE
ULTIMATE SOURCE OF VALUE AND CREATING AN
ENVIRONMENT WHERE THEY CAN MAKE A
DIFFERENCE
- Software Development is ultimately a creative endeavour.
• Like Cooking.
- People are not just cogs but can contribute to be more than the
sum of all there parts
- recognize individual human beings as the ultimate source of
value
60. Empower the team
• WE BOOST PERFORMANCE THROUGH GROUP
ACCOUNTABILITY FOR RESULTS AND SHARED
RESPONSIBILITY FOR TEAM EFFECTIVENESS
- Teams can achieve incredible things when faced with the
challenge.
- Ensure that the focus is on the team and individual recognition
- group accountability for results (i.e., the whole group is singly
accountable, no in-team blame)
61. Customize
• WE IMPROVE EFFECTIVENESS AND RELIABILITY
THROUGH SITUATIONALLY SPECIFIC STRATEGIES,
PROCESSES, AND PRACTICES
- No solution is exactly the same twice
- Even the same problem will be solved in multiple ways by the
same team
- situationally specific strategies, processes and practices. (i.e., no
one answer, folks, get used to it)
62. What’s this got to do with
Project Management?
• Good Projects for me come down to four items:
- Good People - their hearts and minds;
- Good Situationally specific strategies - all recommendations are
specific to the context at hand, there are very few really general
strategies to follow in all cases
- Frequent Feedback - close in and end-to-end.
- True Delegation
• True Delegation is not having someone do a task like you would
• True Delegation is about trusting teammates by providing an end state and
letting them determine the path
• True Delegation is letting teammates make decisions, even when thier
decisions do not agree with your own
63. Is my client ready?
• Rather than consider Lean Software Development as an
approach that fits every client and project, there
definitely is a continuum of appropriate project
methodologies
- Some clients have predictability, procurement, and legislative
requirements that prevent full Lean adoption
- Some clients have more discretion
- Almost never does a first time client do Lean fully. It requires
trust to be built up!
- Some projects even within the same client may be a better
candidate for Lean. (business facing versus compliance)
65. The Test
• Ask your client the following two questions and ask
which one better describes them:
- A successful project will be about delivering the scope and or
solution we have defined in alignment with the project budget
and schedule.
• Predictability
• purchase
- A successful project will be about starting with the scope and or
solution but ultimately delivering more business value and a
solution we cannot anticipate currently.
• Value
• Partnership
