MS Project and Scrum

A few words

I don't fit into the category of guys who say you can't use MS Project with Scrum. I say it depends on the size and scope of the project. It can be used well in case you have non-software development related tasks too.

Example:

Project objective statement: A casino solution for accounting, player tracking and payment processing within 1 year for 1 million EUR.

Dependencies and high level tasks:

• Hardware
• Hardware development
• Software development
• Testing phases
• Shipment dates
• Custom clearance
• Network implementation
• Installation at the venue
• Acceptance dates
• Approval dates by authority
• and many more

The development of the software (Scrum process) is just a piece of cake. The level of details in MS Project about the software development depends on how accurate one wants to track and on the breakdown of the whole project (divide and conquer). I can have one bar "Software release - New Payment System" with the start/end date based on the burn down chart or I can put in every Sprint. One has to assure to provide the right detail of the project and to make deliveries and phases manageable.

How can you make it work?

• Don't put low level tasks into MS Project, don't overload yourself with small activities, make them part of  a larger deliverable
• Choose the right level of detail
• Define the right process for the project and combine useful methods of miscellaneous management philosophies (IPMA process, PMI process, Scrum, Kanban, spiral model, etc.)

Example:

MS Project - Sprints only
Only sprints are used and later one can add other Sprints in case the project is going to be late or non software dependencies need to be tracked. The Backlog list is copy and paste from Excel.

Info
Story points	160
Stories	40
Team size	2	engineers
Sprint duration	2	weeks
Velocity	10	SP p. Sprint
Total sprints:	16	Sprints
Weeks:	32	calendar weeks
Duration p. Story Point	2	days

Burn down chart

In this case it is tracked on sprint level which is not really informative, but gives an estimate about the end date.

MS Project - Sprint level

A  more accurate option is to move the stories selected into the specific sprint before a sprint starts. The team needs 2 days for a story point. Higher tracking level means more work do update the data. It depends on the needs. Tools like Excel or MS Project should help but it shouldn't be a burden on the project manager.

MS Project - Sprint and Features aka Stories

Links:
Burndown chart - explaination

Post of the day - Management mistakes

An interesting post about manager mistakes by Ian McAllister, General Manager at Amazon.
I personally like the following:

 

Performance:

• Being slow to deal with performance issues

Carreer development:

• Not getting to know your employees
• Not investing in developing your employees

Leadership:

• Thinking too small, plan to grow it 10x or 100x
• Poor delivery of unpopular decisions, The more important, or more unpopular, the greater the need to manage delivery
• Being slow to resolve team pain points

Recruiting:

• Not investing in sourcing
• Lazy recruiting

Hiring:

• Not being clear on the requirements of the role - Inexperienced managers don't spend time thinking about exactly what they need.

Organizational Development

• It sucks to have two bosses, good managers seek to have clear lines of authority
• Letting the team get overloaded

Visibilty

• Taking the credit for their team's work instead of redirecting to the team or team member
• Forwarding the blame on team members

It has some points to ponder: Quora link

Project Management Process by IPMA – Project Start and Kickoff

What is the objective of the project start?

Project start is about defining plans, phases and the approach how to achieve the project goal.

Objective of the project start process:

• Scope is defined.
• Phases of the project are defined.
• Overall project plans (budged, resources, work breakdown structure (WBS), milestones, Gantt, organization etc.) are done. In case of large scale project high level plans are prepared roughly and will be fleshed out at follow up sessions. Project handbook framed.
• Project organization is implemented.
• Common understanding of the objectives
• Teambuilding has started.

Step within the framework by IPMA:

How does project start/setup work?

 

Project-Setup

Preparation:	Getting understanding of the scope, meeting project sponsor/customer, preparation of the workshop.
Planning workshop:	Planning meeting to prepare a rough plan to achieve scope, time and cost (tripe constraints) of the project.
Follow Up:	Follow up meeting / discussion based on the results of the planning workshop
Project sponsor approval:	Getting approval for the project plans (when, how, who, what)
Preparation:	Preparation of rough project plans, paperwork for project sponsor meeting
Preparation for customer meeting:	Giving an high level overview of the project and closing of Project - Setup.

What is important about the planning workshop (Kickoff Meeting)?

• Making the expectations and goals of the workshop clear
• Communicating non goals
• Workshop schedule and agenda

 Example Kickoff-Meeting:

Project: Family house

• Date: January 10, 2014
• Participants: Barney (PM..Project Manager), Ted(Engineer), Bob (Construction)

Objective:

• Clarify roughly the scope (characteristics of soil, construction system, construction, construction work, specification of family house)
• Define the phases of the project (eg. define construction system, engineering, construction work, handover)

Non-objective:

•  Implementing outdoor installation and facilities

Agenda:

Time	Subject	Who
8am	Welcome	PM
8:30am	Brief overview and introduction	PM and participants
8:45am-10am	Scope discussion	All
10am-12am	Phasing the projects and defining roughly project-plans	All
12pm	Lunch	All
1pm-2pm	Debriefing	PM

PM..Project Manager
Documents:

Plans (cost, architecture, quote)

 

Input:

• Projectcharter

 

Output of Project-Setup:

• Project handbook (p-plans)
• Minimum recommendation: Scope, Work Breakdown Structure, Milestoneplan, Gantt chart, Roles, Organizational chart, resource plan, cost plan

 

 

Post of the day - Colossal Failed Government Information Tech Projects

Colossal Failed Government Information Tech Projects And Why They Failed. A picture says more than thousands words. The causes are true for about 90% of failed projects (also smaller ones).The link to the post is below.

Links:
Curiousmatic.com - Colossal Failed Government Information Tech Projects

Project scope

Why is the scope of the project so important?

This chart below says more than thousand words. An unclear scope or a changing scope of projects is the root cause of software defects which lead to troubles afterwards.

Survey based on 10 software projects

Forty percent of all troubles can be avoided if enough brainpower and work is put into defining a crystal clear scope and a fitting work breakdown structure out of requirements. I have seen tremendous scope changes in IT projects and afterwards everyone was wondering why it went so bad. In construction business, one builds rarely a family house and in the middle it is going to be changed to a skyscraper

Why is software project management so difficult?

Everyone has read about the ninety-ninety rule. "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." by Tom Cargill, Bell Labs.
Total development time is 180% of budgeted.
McKinsey and University Oxford surveyed more than 5400 IT projects in June 2012. The study is not showing promising results for large scale projects and the picture is similar for smaller IT projects.

IT projects cost overrun

 
A couple of years ago I worked in real estate development, mostly constructions of commercial buildings and I didn't see these cost overruns which are almost symptomatic in IT. Especially some software departments are quite creative to hide total software project cost by accounting development cost under support or enhancement cost.

Why is it so complex and difficult?

IT projects	Construction projects
- Modern software companies have teams distributed around the world, but they work on a specific project.	- Construction happens at specific location with persons responsible at the same place (except tunnel projects).
- Software project progress is not immediately visible to stakeholders. It is virutal and intangible.	- Construction project progress is feasibly even nonprofessional persons can understand the progress.
- A capable single developer can actually create an entire shippable product.	- A single construction worker can't build a object.
- A lot of software processes start really late with acceptance and integration tests which shifts discovery of flaws within architecture or functionality.	- Acceptance of progress of construction work happens often (basement, framework, per story, installation
- Different opinions about the right architecture	- Architecture is settled when constuction starts.
- Scope isn't clear
Software is typically a process of discovery. Teams learn what needs to be developed as the product evolves.

Note: Construction projects have other pitfalls but tasks are easier to track.

What do I do to make them better manageable?

• I prefer software process with short iteration cycles e.g. Scrum, Scrum extended with Kanban limits, typical spiral models with iterations depending on project size.
• If I have to work within a specific process close to a linear model, I try to enforce a heavy testing culture
• Being painstaking about a crystal clear scope and the understanding of the scope
• Divide and conquer strategy (small parts are better manageable, integration as soon as possible)
• Good estimating (Analogous estimating, three-point estimates and include probability)
• Making the development visible by using whiteboards, Kanban boards, Standup meeting  per team (15min max)
• Making the software development visible to stakeholders (management, tester, other teams, end user etc.)
• Having a risk plan (risk, weight, impact matrix) and cost control in place

Links and Books:
Software-Engineering-A-Practitioners-Approach
http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Project Management Process by IPMA – The Process

The process

The project management process by IPMA provides the framework and methods to achieve the project goal within the triple constraint (time, scope and cost/quality). The process itself is lighter than the PMI approach and is focusing on people skills. Project management competences are outlined in the IPMA Competence Baseline (ICB). It is divided into: Technique, Behavior and Context. I want to lead you through the process by building a family house as example.

Project Management Process

Project Start (aka Project Setup)

It is about defining the projects plans (P-Plans) and phases of the project based on the inputs of the Project-Charter (P-Charter).

Project-Charter	Family house
Description:	Family house with flat roof and a few doors and windows build within 3 months after contracting.
P-Start Date:	January 20, 2014
P-Start Event:	Signature on the contract
P-End Date:	April 20, 2014
P-End Event:	Acceptance by Fred the customer
P-Objectives:	Whole construction from basement to roof
P-Non-Objectives:	To build a skyscraper
P-Category:	Small project
Main Tasks:	Basement, first story, roof, installations
Resource:	Bob the builder
Costs:	1 million USD (estimate)
Project Sponsor:	Fred the customer
Project Manager:	Barney
Project Team:	Barney, Ted the architect, Bob the builder
Date and Signature:	Barney

These are the tasks which are critical for the setup of the initial phase:

• Outline the project regarding scope, time and social context and boundaries
• Defining the phases of the project
• Defining the project organization
• Defining the project start process (kick-off meeting)

Inputs:

• Project charter

Methods:

Brainstorming, kickoff meeting, expert teams, estimating techniques, workshop, etc.

Outputs:

• Project handbook with the project plans

Minimum recommendation (small projects):

• Work Breakdown structure,
• Roles
• Organizational chart
• Milestone plan
• Schedule (Gantt chart)
• Resource plan
• Cost plan

 Links & Books:

John Hermarij, Better Practices of Project Management based on IPMA-C and IPMA-D- 2nd. Edition, Netherlands, Van Haren, 2001

ICB and pm baseline 3.0, Austria, IPMA, 2013

Team building within a fast changing environment

A few words

I like the Microsoft software process. Basically they are using SCRUM on large scale (~1000 engineers) with few rules and a debt commitment by teams. Debts have to be delivered by teams. I don’t want to spend words on team forming, storming, norming and performing model by Tuckman. I adapted the Microsoft approach a little to make it work for my company’s environment where team members often change and I am confronted with virtual teams all the time.

 New teams to build:

• A short kick off meeting 
• Face to face is best
• Sometimes virtual because of our matrix and international organization
• A few ground rules, fewer rules is better
• Commitment by team regarding debts

Debts are:

• Minutes after a meeting (usually I do them)

• Chosen software process, here it’s SCRUM

• Only a certain bug amount is tolerated. If a threshold amount is reached the team has to go into bug fixing mode.

• Non-functional requirements e.g setup has to work after each Sprint

• No issues about functional development, because everyone loves this work usually.

Existing teams

Check for common rules. It can be truly discouraging to team members if a product owner/ project manager doesn’t know about existing ones. Once I had an Asian team and they were used to have a short tea break at 11.30am. I didn’t know at that time and scheduled meetings regularly. Later, I discovered and the whole team thought I wasn’t happy with their work which wasn’t the case. 

My debts as project manager

• A clear communication of scope and expectations
• Discussion to understand the current game field
• Listen to the end
• Keep the team environment great

Retrospective

I am trying to do it regularly on short periods. I don't have a good experience with feedback sessions after a half year or year has passed by. Much has been forgotten and usually one gets a vague picture (not specific, measurable, appropriate, relevant and timely). I just use it to adjust and tune, means  a step at a time, not a stormy way changing everything at once after each session.

Usage of collaboration tools to improve working situation of virtual teams

• Kanban boards, I really like Trello, it is great to present tasks in a swim lane view
  

  

  Trello: Kanban tool

• Webex / Lync with drawing and highlighting feature
• JIRA, only internally because if one is confronted with quick changing processes and external contributors it hasn’t the flexibility I need especially because I have to go through IT

Links:

Agile software development with Microsoft Visual Studio, youtube

How does Agile, Scrum and Kanban scale to large projects having 10,000s of features, Quora

Why just making notes for me? Why not making them for everyone?

Usually I take down a lot of notes during my work to have a kind of personal skill database and to remember management and soft skills. At work I like to share knowledge and I had this idea now. I thought I can make findings/experience public with a blog. It might be an experiment with unknown outcome, but I look forward to sharing best practice and discussing them. Happy blogging, danny