Project Management

Scope - Design - Development - Rollout

These are personal notes. You are welcome to read them.

Contents

• Introduction
• Project Intake
• Project Plan (documentation page)
• Scope
• Stakeholders
• Design
• Development
• Tests and rollout
• Maintenance
• Best Practices
• Misc 

Project steps:

• Scope
• Design
• Development
• Tests and rollout
• Maintenance

Introduction

Vocabulary

The Business Analyst often starts with the scope, after receiving the Business Case

Project Intake

In the movies, the mission is given in a short and concise phrase before the tape recorder turns to smoke. In real life, the description of the mission is the smoke... The project manager has been "volunteered", deadlines have been mentionned, a vague, smokey description has been given... What next? Transform the smoke into a project definition with:

• Starting date (add to my diagram in "timeframe")
• A fixed end date (~deadline, add to my diagram in "timeframe")
• Specific goals and conditions (in my diagram). The goals should be the answers to the question "WHY?".
• Defined responsibilities (=authority?)
• A budget (=resources)
• A planning (result of first part in my diagram)
• Parties involved (~resources)

To do:

• Decide if I want to give the job back ...
• Is this a project or a problem that management want to get rid of? If I can define the project with the elements above then it is a project.
• Why? --> goals
• Define the playing field: who is involved and why? Draw a picture with stakeholders and the relationships between them. (For the groups, associate a leader or representative, because people hold stakes, not organizations).
• How did management decide on the budget? How did management decide on the deadlines? The answers will give insight on stakes.
• Try to learn about the history of past projects because this will

The next step is the plan: see project plan documentation.

Think about the boss and his/her:

• Goals and objectives (stated / un-stated)
• Pressures on him/her
• Strengths/weaknesses
• Communication style (formal / informal)

Then

• Put on paper
• Devise a plan of action with framework
• Show it.

Project Scope / Expression des besoins / Defintion of Needs

Determine the needs so as to clearly define the objectives of the project.

In addition to this section, read the Business Analyst notes

Essential elements for success:

• A serious sponsor, who is really interested and assumes the reponsibility of the project
• A sense of urgency or of need
• A partnership between operations and IT
• Also: analytical culture (=decisions based on facts) and feasability

Determine:

• Strategical initiatives of the company
• Related performance criteria
• "processus métier"
• What impact will the additional information have on performance?
• Hierarchy of needs

Le champ fonctionnel contient toutes les fonctionnalités du la future application; le périmètre fonctionnel constitue une délimitation entre ce qui fait parti du projet et ce qui en est exclu. --> list of fonctionnalities and elements excluded

Plan for Scope:

• Preliminary goal definition with top management
• Gap analysis if a system exists
• Meetings with users
• Final goal definition with top management
• Preparation of a project plan and presentation, including a detailed plan for design
• Deliverables:
  • Scope document (objectives, elements excluded and success criteria)
  • Justification: approximate costs and expected returns
  • Project plan
• Presentation to top management

During the meetings, determine:

• Strategical initiatives of the company and link with the project
• Explore the "processus métier"
• What impact will the additional information have on performance?
• Hierarchy of needs (see below)
• Expected advantages of the projects: gains in productivity, gains in efficiency,
• Identify different alternatives (expensive <--> simple)

Notes on team building and kick-off meeting: see page "proj_notes.html"

All this helps identify the needs ⇒ and therefore the preliminary objectives. These objectives must represent a joint effort between operations and IT, they should be significative (visible, with impact on performance) and manageable (=start small). Put down on paper:

Plan project:

• Project identity
• Resources
• Preliminary plan
• Communication plan: often for team, less often for sponsors (state of advancement and issues), also for users (functionalities, big changes, delays), + informal.
• Develop follow-up of success indicators
• Define the methodology: define the steps, the deliverables at each step and the responsibilities at each step
• Change management process: refuse, ajust (the scope shifts) or enlarge (the scope becomes bigger ⇒ higher cost and more time). Decision by operations & IT together.
• Issue list, modification list (modifications of current project), list of requests for improvements (for later).
• Eventually, add a description of the current system

Business Case:

• Short description
• Reasons for change
• Assumptions used to prepare the business case
• Benefits that the change will to the organization
• Costs of the operation

Determine the hierarchy of needs and feasibility along two axis and position each element/functionality in one of the squares:

• Feasibility, availability of data, facility of implementation... These are technical criteria.
• Priority of needs according to impact on the organization, strategical importance, return on investment... These criteria are determined by management.

Roles

Risks linked to requirements phase: see proj_mgmt.html

Stakeholders

(See also Free Software Project Management Training)
See also the Business Analyst notes

To this end, prototypes, plans, design documents, reports, evaluations, ... are important.

A project is a show with actors (project team) putting on a performance to the stakeholders.

	What I see	What I do NOT see
A project is all about "the flow of stakes". It is about making everybody happy by offering what each person expects to see. The stakeholders drive the project. The stakes can be fears or they can be wishes. But the stakes are rarely clear. Stakes are packaged in requirements. Listen to the requirements knowing that there are stakes behind.
Negotiate the requirements if there are conflicts. The stakeholders will accept changes to the requirements if the stakes are not moved. If the stakes are not touched, a win-win situation can be found.		?
Therefore, an important task is reassuring the stakeholders that they have been heard (i.e. their stakes are taken care of). Because the stakes can only be guessed, constantly give feedback to the stakeholders on the requirements of the project. This should reassure them that their packaged stakes are in place.
Listen to the feedback from the stakeholders and redo a cycle of negotiations if necessary. Picture from www.softwareprojects.org

Risks linked to stakeholders: see proj_mgmt.html

Design / Analyse fonctionnelle

Final document is "Design Document" or "Cahier des charges"

See also the Business Analyst notes

Talk with the users, about their work and their objectives. Then talk informally with the those who know the data model. When the users' needs become precise, start talking formally with the computer department to explore the details of the data sources. Start with small groups to gather a lot of information, then meet in large groups so that a consensus may be reached by all parties involved. Roles: futur users, main interviewer, scribe, optional observers

During the meetings, determine:

• What is to be accomplished?
• Related performance criteria (how will we know that we will be performing well? what determines success?)
• What are the current obstacles to success? What are the current problems?
• What type of information is required?
• Explore the "processus métier"

Roles

Prototypes

Purpose

• Validate the requirements and finding missing pieces.
• Lower costs of trying different designs and layouts
• Verify that the design

Time-box: Because prototyping is fun, creative, and dynamic, the scope can expand easily beyond the original plan. Therefore, time-box the prototype to an effort of a few weeks.

Throw-away code: The big decision around prototypes is about the re-use of code. The tendancy is that once a program works, it is used forever. The other tendancy is to do "quick and dirty" code to get the prototype working as soon as possible. Therefore, if any code is expected to be re-used, treat the development as a phase 1 or partical phase with a proper design effort.

Types of Prototypes

• Visual prototype, emphasizing the visual aspects of the future application.
• Proof-of-Concept prototype, focusing on specific risks and unknowns. Keep the scope narrow, with no user interfaces.
• Operational prototype: I do not think that this is a prototype, but an early phase of the application.

Prototyping Guidelines

• Keep to the original purpose of the prototype.
• Keep the scope small
• Keep expectations about the prototype as an imperfect shell
• Ask for and document feedback on the prototype

Development

Roles

Integration, Tests and Rollout

Tests

• Cases of simple and normal use
• Abnormal cases (are the errors reported properly)
• Cases that test the limits

Roles

Rollout Checklist

Connection to database

• Create the user ID
• Implement a way to store the password
• Define the database connection parameters
• Make sure that the switch is made from QA databases to PRD databases

Database Tables

• Create the tables
• Grant permissions for read-only and eventual read-write
• Check permissions for the specific user that the application will use

Performance

• Define indexes
• Run explain plan on typical queries

Application

• Modifications have comments in the code, with date and name
• Each reported bug is tested (unit test)
• Each new development is tested (unit test)
• Keep record of the changes made
• All new code is imported from version control
• Change the version number
• Compile the application, views and procedures
• Create or modify setup/configuration files

Tests

• Run setup if necessary, copy the newest executable
• Do the final tests when ALL development is completed
• Test the application, with special attention to those parts affected by the recent changes
• Test the reports, especially those that were modified.

Closing[2]

• Get final approval from stakeholders (consensus that the project is completed / dropped)
• Inform everybody of imminent end of project
• Finish all contractual commitments
• Formally transfer responsibility to whoever continues
• Handle the reassignement of people
• Release the equipement and materials
• Account for all money spent
• Finish the documentation
• Thank everybody, celebration

Maintenance

Keep track of:

• The load
• Incidents
• Degradation of performance

Watch:

• Backups
• Followup after incidents

Best Practices

Medium to long-term vision

Don't take too many decisions in urgency

Notion of project

Start date, end date, ...

Key Indicators

the advancement of operations
the consumption of resources
the duration of implementation

Group changes into versions

Regroup all corrective and evolutive changes into versions, each thouroughly tested.

 

• Do not let the boss delegate blindly to you the definition of the project scope just because he doesn't undersand anything about the new technologies. It is the management who must define the goals.
• Do not let old processes continue in parallel with new processes. The old processes should evolve with the new tools.
• Be sponsered by someone with leadership and experience.
• Consider potential clients even if they "are behind", even if they know nothing about Internet, even if their connection is slow, even if they cannot understand a web site.

Define Goals[2]

• Are the goals clear and specific, can someone else understand them?
• Are the goals realistic?
• What is the finish date?
  None? --> the project will never finish
  Too short --> see "unrealistic"
• What are the deliverables (results, goods or services)?
  And what are the measures of quality?
• Do my boss and the stakeholders agree on the goals? (And do I agree?)
• Does everybody agree on who is responsible for what?

Some Success Factors

• Drop the project if it does not correspond to the strategy of the organization
• Determine who is sponsoring the project
• Define the scope of the project
• Implicate the (real) clients
• Ask for realistic budgets and deadlines
• (Try to) analyze the (real) risks
• Choose a good timing for implementation
• Evaluate technological impacts
• Evaluate impacts on operational processes
• Evaluate the need for training
• Make the prototype close to future reality
• Allow for enough testing
• Separate the roles: overall picture (maîtrise d'oeuvre) <--> implementation (maîtrise d'ouvrage)

Negotiation[2]

• Center on my needs (and define them first), define what I want and list what I would like.
  What does the other side have to offer?
  What do I have to offer?
• What do I know about the other side?
• Suggest a neutral environment (lunch...)
• Make my situation clear
• Go slow if necessary in the beginning.
  Other options may be negotiating in writing
  Show the door if the other side asks for too much
• Do not let myself be forced into something
• Contact the other side after 1-2 weeks
• Accept only the acceptable

Stuck?

1. Define what has to be done, by phases
2. Put names on the tasks. Split the tasks if necessary.
3. Write down what the person should know (see "delegating"), i.e. define what has to be done --> goto (1)
4. Group tasks and break them down

Miscellaneous

Biography

• [1] Ralph Kimball: Concevoir et déployer un data warehouse, Eyrolles, 2000, traduction de "The Data Warehouse Lifecycle Toolkit, Expert Methods for Designing, Developping and Deploying Data Warehouses"
• [2] Sunny and Kim Baker: The Complete Idiot's Guide to Project Management, Alpha Books, 1998