How Agile Manager Start/Manage Projects

Project managers need a broad range of skills. Here is the complete DNA/guide to know
- How to Start a Project,
- How to Execute Project and
- How to Monitor and Control Project &
- How to Close the Project

Here we'll try to cover how we manage project in Agile/MS Environment.

1). Initiation Phase:

• Business/Client
• Collect Ideas/Initiatives Meeting Strategic Goals
• Create Vision & Scope Document 
• Identify BPO/PM/Stakeholders
• Raise HLE Request
• Request Project Proposal/Charter from Consulting Team
• Consulting Team - Onsite
• Review Scope Document
• Create High Level Business Requirement
• Create Conceptual Design Document
• Identify High Level Risk/Issues/Dependencies
• Generate High Level Estimates
• Review/Assess if additional capacity is required for fulfillment
• Submit Project Proposal / Project Charter (containing all above details)
• Business/Client
• Review & Validate Project Proposal/Charter
• Get Finance/PPM Approval
• Determine Project Mode Hybrid/Agile
• Submit Project Work-Order to consulting team
• Initiate Project Kick-Off

2). Planning Phase:

• Business/Client
• Conduct Sprint Zero (Including Consulting Team and Other Stakeholders/Teams involved)
• Consulting Team
• Conduct Sprint Zero
• Elicit/Understand Business Requirement, Define Scope, Collect Prioritization, Define MMF
• Writing Features/User Stories, Writing Acceptance Test Cases, Conduct Three Amigo Sessions, 
• Estimate User Stories (ROM Estimates)
• Create High Level Design Document, Review Designs With Review Board
• Create Ux/Wireframes
• Highlight High Level Risk, Assumptions, Constraints, Dependencies, Impediments etc.
• Generate Project Roadmap/Schedule based on Demand-Capacity & Project Prioritization & Client Commitment Dates, UAT Dates etc.
• Make Capacity Reservations & Gain Approval from Offshore DM
• Send/Gain Approval on Sprint Zero Output (including above) from Business

3). Execution Phase:

• Business/Client
• Attend Sprint Planning Meeting
• Attend Daily Stand-up Meeting
• Attend Sprint Review Meeting
• Resolve Impediments
• Approve Defect Deferral
• Attend Sprint Retrospectives
• Consulting Team - Offshore
• Conduct Sprint-Pre-Planning Meetings, Understand Requirements, Estimate User-Stories (LOE)
• Sprint Execution
• Create Detailed Design Documents
• Branching, Develop Code, Unit Testing & Code Review
• Create SQA Test Cases
• QA Deployment
• UAT Deployment
• CIRT Fixes, Code Merging etc
• Consulting Team - Onsite
• New Project
• Conduct Sprint Zero
• Existing Project
• Conduct Sprint Planning with Business
• Generate Next Sprint Requirements
• Generate User Stories,  Conduct Three-Amigo, Estimate User Stories (ROM), Update/Create Acceptance Test Cases
• Update High Level Design Document (if any)
• Conduct Design Review Meetings (if any)
• Update Project Roadmap (if required) based on LOE Estimations, Requirement 
• Review/Gain Approval -  Project Roadmap & Revised Capacity (If changed)
• Create Release Readiness Process
• Raise RFC
• Identify Impacted Components
• Identify Risk/Dependencies
• Create Test Plan
• Create Deployment Plan/Rollback Plan
• Conduct Sprint Review with Business
• Highlight/Remove Impediments
• Conduct Sprint Retrospectives
• Any MMF/Reprioritization
• Reports
• Executive Summary
• Weekly Status Reports
• Weekly Capacity Reports
• Create/Update Risk/Issues/Constraints/Assumptions/Dependencies

4). Deploy & Stabilize:

• Business/Client
• Provide Production Cut-Over Dates
• Business IT Validator Names
• Consulting Team - Offshore
• Update Release Readiness Process
• Create & Upload Release Notes/Artifacts 
• Submit RFC
• Perform IT Validation
• Consulting Team - Onsite
• Conduct Deployment Walkthru
• Support Deployment In UAT/Staging
• Perform IT Validation
• Facilitate UAT Testing
• Facilitate Defect Deferral
• Gain UAT Approval
• Get Business Sign-Off
• Facilitate Production Cut-over

5). Closure & Warranty Support:

• Business/Client
• Collect End-User Feedback
• Provide Project Retrospection Comments/Feedback
• Consulting Team - Offshore
• Create Handover Document
• Handover to L3 Support Team
• Provide Warranty Support
• Consulting Team - Onsite
• Conduct Project Retrospection
• Update Capacity Reservation
• Update/Close Project WorkOrder
• Conduct Project Retrospection
• Provide Warranty Support

Hope this helps!!

Arun Manglick

PM - My Project Management Style/Approach/Skills

Project managers need a broad range of skills.
Whether or not you hold the official title of project manager, chances are you'll be called upon to lead some sort of project at some time.
This short quiz helps you determine how well you perform in the eight key areas that are important to a successful project.

Project Manager should have below PM skills.

• Project Planning/Scheduling/Execution:

1. When a project begins, I work with its sponsor to negotiate and agree specific deliverable.
2. At the start of a project, I formally outline what, why, who, how, and when with a Project Initiation Document – so everyone can understand how the elements of the project fit together.
3. I prepare a specific timeline and sequence of activities, and I use this schedule to manage the overall project to ensure its timely completion.
4. I communicate what needs to be done by what deadline, and expect the people to whom I assign the work to be responsible for breaking down the work packages into smaller and more manageable pieces.
5. I outline clear expectations for the project team, and I manage their individual and collective performance as part of the overall project evaluation process.
6. I give people a deadline to complete their project work, and then I expect them to coordinate with others if and when they need to.
7. When a project gets behind schedule, I work with my team to find a solution rather than assign blame.

• Project Management/Stakeholder Management/Monitoring

1. I consider a variety of cost alternatives when developing my original project budget plan.
2. I identify as many potential project risks as I can, and I develop a plan to manage or minimize each one of them, large or small.
3. I routinely monitor and reevaluate significant risks as the project continues.
4. I define specifically what the stakeholders need and expectation from the project, and I use these expectations to define and manage the project's scope.
5. I keep all project stakeholders informed and up-to-date with regular meetings and distribution of all performance reports, status changes, and other project documents.
6. Maintain Reserves - Forecasting costs is more art than science, so I include extra funds in the budget and hope that I’m under cost at the end.
7. I present Project Status Information in an easy-to-use and easy-to-access format to meet stakeholders' information needs.
8. Delivering on time and on budget are the most important things for me.

• General Project Management Skills 
• Negotiation – specifically, Integrative Negotiation – is very important for dealing with suppliers and getting the in-house resources you need, when you need them.
• Conflict resolution is another important general skill. From resolving conflict within your project team to managing conflict that arises during negotiation, this is a fundamental skill for project managers. 
• Problem-solving skills are essential. They will not only improve negotiation and conflict resolution skills, but also help with risk management, time management, and quality management. 

--------------------------------------------------------------------------------------------------
Here are more details - PMP 09 Knowledge Areas:

Project Integration 

• Develop a solid understanding of the project's goals.
• Start by producing a Business Requirements Analysis, and then develop a comprehensive Project Initiation Document, which covers the basic project needs and outcomes, so that everyone can understand the project's goals. 
• To prepare this critical, high-level document, you need to understand the phases and processes of project management. This overview will help you become better prepared for what's ahead.

Scope Management 

• Projects have a nasty habit of expanding as they go along, making it impossible to hit deadlines. To control this “scope creep,” it's essential to define the scope at the very start of your project based on the Business Requirements Analysis, and then manage it closely against this signed-off definition. 
• For more on how to do this, see our article on scope control.

Time/Schedule Management

• A project's scope can easily grow, and so can the time needed to complete it. 
• For a project to be completed successfully, despite all of the unknowns, it's important to clearly define the sequence of activities, estimate the time needed for each one, and build in sufficient contingency time to allow for the unexpected. 
• With this information, you can develop a Project Schedule and then begin breaking it down into very specific pieces of work using a Work Breakdown Structure. 
• A schedule often isn't enough. To keep track of the various activities, Gantt Charts and Critical Path Analysis are often helpful.

Cost Management 

• To determine what a project will cost, you must be systematic with your estimating, budgeting, and controlling. 
• Also, be aware that many project decisions will have an impact on cost. 

Quality Management 

• To achieve quality, ensure that you actively manage project benefits. By continuously referring to the benefits that the project will provide, you keep client quality at the forefront – and you won't waste precious time and resources trying to achieve an inappropriate level of quality. 
• An effective project manager knows the importance of checking that project outcomes are consistent with needs. The Deming Cycle (Plan-Do-Check-Act) and Business Testing are important tools for this, as they both force you to consider the needs of the end users. 

HR/People Management 

• Right mix of interpersonal and political skills is just as important as the right technical skills. 
• To help your new team start working together effectively as soon as possible, develop a Team Charter and outline performance expectations. 
• Use well-informed task allocation and appropriate team management skills to keep the project team on track and working productively. 
• And be prepared to help people through the Forming, Storming, Norming and Performing stages that so many teams go through.

Communication

• As with most situations, effective project communication means communicating with the right people at the right time and in the right way. 
• To do this, Stakeholder Management is essential. When you analyze your stakeholders, you identify who must be kept informed in full, and who needs less intensive communication. This can save you a lot of time, and helps you maintain good relationships with people involved in the project.
• Project Dashboards are great for presenting project updates in a way that people can quickly understand. For longer projects that require periodic status reports, Milestone Reporting is effective for capturing the essentials of a project's status.

Risk Management 

• Project managers must understand which of the risks to their plans are significant. An Impact/Probability Chart will help with this. 
• From there, develop a plan for monitoring and controlling the major risks involved in your project. 
• Using your Risk Analysis, develop options to reduce risks, prepare Contingency Plans, and decide who is responsible for which parts of risk response.

Project Procurement 

• Unless your project is in-house, external suppliers will generally have a large impact on your costs. Suppliers will also affect whether the project delivers on time and to specification. 
• Take the time to define your needs in a Request for Proposal document, and then use an appropriate Procurement Management approach to select the best supplier.

Reference: http://www.mindtools.com/pages/article/newPPM_60.htm

Regards,
Arun Manglick

Mike Cohn - Agile Concepts

Chap 02:

Why Planning Fails

·         Planning Is By Activity Rather Than Feature

·         Features Are Not Developed By Priority

·         Estimates Become Commitments

·         Multitasking Causes Further Delays

·         We ignore uncertainty

Chap 03:

An Agile Approach To Projects

·         Work as one team

·         Work in short iterations

·         Deliver something each iteration

·         Focus on business priorities

·         Inspect and adapt

An Agile Approach to Planning - Multiple Levels Of Planning – Onion Planning

Chap 05:

Estimating In Ideal Days:

·         Ideal time and elapsed time are different.

·         The ideal time of a game of American is 60 mins. However, elapsed time (with all interruptions) could be 3-4 hrs.

·         Estimating in Ideal Days is easy than estimating in Elapsed days.

·         Estimating in elapsed days requires to consider all of the interruptions that might occur while working on the story.

·         In this way, ideal days are an estimate of size, although less strictly so than story points.

·         When estimating in ideal days it is best to associate a single estimate with each user story. Rather than estimating that a user story will take four programmer days, two tester days, and three product owner days, it is better to sum those and say the story as a whole will take nine ideal days.

Chap 06:

The Estimation Scale

Two estimation scales I’ve had good success with are:

·         1, 2, 3, 5, and 8

·         1, 2, 4, and 8

There’s a logic behind each of these sequences.

·         The first is the Fibonacci sequence. I’ve found this to be a very useful estimation sequence because the gaps in the sequence become appropriately larger as the numbers increase. A one point gap from 1 to 2 and from 2 to 3 seems appropriate just as the gaps from 3 to 5 and from 5 to 8 do.

·         The second sequence is spaced such that each number is twice the number that precedes it.

These non-linear sequences work well because they reflect the greater uncertainty associated with estimates for larger units of work.

Deriving an Estimate

The three most common techniques for estimating are:

·         Expert opinion

·         Analogy

o    When estimating this way you do not compare all stories against a single baseline or universal reference.

o    Instead, you want to estimate each new story against an assortment of those that have already been estimated. This is referred to as Triangulation.

·         Disaggregation

Chap 08:

Choosing Between Story Points and Ideal Days

1.     Why Story Points:

·         Story points help drive cross-functional behavior

·         Story point estimates do not decay or has longer shelf life

·         Story points are a pure measure of size, Ideal Days are Not

·         Estimating in story points is typically faster

·         My ideal days are not your ideal days

2.     Why Ideal Days:

·         Ideal days are easier to explain outside the team

·         Ideal days are easier to estimate at first

·         Ideal days make velocity predictions easier

Chap 12:

Splitting User Stories

·         Splitting Across Data Boundaries

o    Splitting US – Support Local & International phone numbers.

o    Splitting US - Payoff my loan & Refund if paid more

·         Splitting On Operational Boundaries (CRUD)

·         Removing Cross-Cutting Concerns

o    Splitting US – One with and Other without support for the cross-cutting concern (security, logging, error handling, and so on)

·         Don’t Meet Performance Constraints

o    Splitting US – Functional & Non-Functional Requirements

·         Split Stories of Different Priority

o    If the user enters a valid user name and password, she is granted access.

o    If the user enters an invalid password three times in a row, she is denied access.

o    If the user is denied access, she is sent an email stating that an attempt was made to use her account.

·         Don’t Split A Story Into Tasks

Chap 13:

Release Planning:  Release planning (3-6 months) is the process of creating a very high-level plan that covers a period longer than an iteration.

Why Release Planning:

·         Helps the product owner and the whole team decide how much must be developed and how long that will take before they have a releasable product

·         Release conveys expectations about what is likely to be developed and in what time-frame for strategic planning activities.

·         Release plan serves as a guidepost toward which the project team can progress. Without the concept of a release, teams move endlessly from one iteration to the next.

How to Create Release Plan:

·         Determining The Conditions Of Satisfaction / Success Criteria

·         Estimate The User Stories – May be a Feature Level

·         Select an Iteration Length – Two or Four Weeks

·         Estimate Velocity

·         Prioritize User Stories

·         Define Release Plan (Based on Velocity, Launch Date & US Priorities)

·         Feature Driven - If the project is feature-driven, we can sum the estimates of all needed features and divide by the expected velocity. This will give us the number of iterations necessary to complete the desired functionality.

·         Date Driven - If the project is date-driven, we can determine the number of iterations by looking at a calendar. Multiplying the number of iterations by the expected velocity will tell us how many story points or ideal days will fit in the release.

Chap 14:

Iteration Planning

·         Velocity-Driven Iteration Planning

·         Commitment-Driven Iteration Planning (Preferable)

Chap 15:

Selecting an Iteration Length

Factors in Selecting an Iteration Length:

·         How long priorities can remain unchanged

·         Willingness to go without feedback

·         The overhead of iterating

·         The length of the release being worked on

·         A feeling of urgency is maintained

·         The amount of uncertainty

·         The ease of getting feedback

Chap 16:

Estimating Velocity

You have the following three options:

1.     Use Historical Values - Before using them, ask yourself questions like these:

o    Is the technology the same?

o    Is the domain the same?

o    Is the team the same?

o    Is the product owner the same?

o    Are the tools the same?

o    Is the working environment the same?

o    Were the estimates made by the same people?

2.     Run an iteration

3.     Make a forecast

Chap 18:

Planning the Multi-Team Project

Planning a large, multiple team project may require:

·         Establishing a common basis for estimates

·         Adding detail to their user stories sooner

·         Lookahead planning

·         Incorporating feeding buffers into the plan

Regards,

Arun Manglick