Project Management Snippets

I've been following the recent Project Management series on the Register and pulled out a few snippets to act as a refresher of good practices:

Reasons for Budget Overruns

• Software versions not specified or incompatible
• Negligence of service level issues e.g. resilience, disaster recovery, business continuity
• Lack of time for sufficient testing
• Attempts to retrofit security and access restrictions
• Lack of firm control over scope creep - authority and accountability required
• Insufficient built-in contingency
• Lack of regular checkpoints and/or failure to spot early warning signs

When Projects Go Right

• Everyone working from the same page with a clear vision
• Setting of expectations that are challengeable yet achieveable
• Infrastructure and software dependencies taken into account
• Support and commitment from business especially senior management
• Consideration of security, training and support, mobile working, regulatory issues, data storage
• Availability of sufficient resources and skills with flexibility to deal with overcommittment of individuals
• Balance internal politics and sensitivities
• Clear lines of reporting upwards

How not to Project Manage

• Assuming they know what you do - need to make your contributions clear
• Assuming judged on past success - need to have had failures in order to learn
• Assuming estimates are correct - need to research past costs and timings
• Assuming you must always be right - do not need to the know-all guru
• Assuming planning is a shared responsibility - planning, planning, planning!

Project Communications

• Define the audience(s), appropriate levels of info and frequency
• Define how the comms plan will be measured and reviewed
• Time comms to co-incide with project checkpoints/milestones
• Consider variety of comms methods depending upon cost, immediacy, privacy and accessibility

ITIL Revision Cards

Some handy revision cards for the ITIL foundation exams, version 2 and 3, can be found here:

Clavis klw AG

SVN Auto Commits

Schedule this executable and combine with SubversionNotify to automatically commit working copies to the repository and notify changes.

Sources: 

Using Subversion to do automatic backups

Subversion - A Summary Cheat Sheet - Learn svn in 10 minutes

Prioritising Complex Requirements

• Scrum/OpenUp manage requirements in a prioritised "product backlog" stack of work items
• Work items can be functional or nonfunctional requirements, defects or nonrequirements work e.g. reviewing, training, configuring
• At the beginning of each iteration a suitable amount of items are pulled off the top of the stack
• Work items can be prioritised at any time highlighting not only the most complex and valuable items but recording their relationships and dependencies

See: Complex Requirements On an Agile Project

Project People and Project Techniques

Use of the best project tools and techniques do not make a successful project, the education and motivation of the people make the project work. Alistair provided a nice analogy for this:

"Kind of like giving me, a non-fighter, a sword to defend myself against a trained knife fighter – I know I’d be the one getting cut up, no matter the length of the blade. It’s not the blade, it’s the skill of the wielder that matters."

See: Why cant people deliver?

Agile Use Cases

• Text documents which do not describe the GUI or data formats, contain 3-9 steps in the main scenario, are easy to read, at the users-goal level and record decisions made.
• Contain the goal of the primary actor, level of goal, primary actor, main scenario action steps, extension conditions and action steps
• Non-functional requirements should be held elsewhere
• Use cases should not provide a tutorial on the domain, describe program features, span multiple pages, collect formulae
• Use cases should be used to discuss/argue and agree upon functionality, summarise system responsibilities and as a basis for further analysis

See: Agile Use Cases

Reflection Workshops

Some things to think about for iteration/project phase reviews:

• Sanity check iteration estimates and working conventions
• Discuss what to keep, any ongoing problems and what we would like to try for the next period
• Things to keep include sitting close together, daily stand-ups and automated regression tests
• Problems include many interruptions, requirements changing too often and people making changes without notifying everyone
• Suggestions for change include hours of interrupted work, use of coding standards, more unit or acceptance tests and occassional pair programming
• Constrain the time allowed for the discussions to focus on concrete suggestions

See: Reflection Workshops

Cost of Fixing Defects

A simple picture to describe a common problem scenario...
See: Closing the Gap

Agile in Practice

This article discusses some of the results from Agile surveys: Newsflash: Agilists Write Documentation!

One surprising result:

• A very small percentage of teams use Software-Based Modelling Tools to generate code

And several others which confirm what I already believed:

• Many teams use sketching to think and communicate and then capture key diagrams
• Nearly all teams use some form of modelling for up-front requirements and architecture envisioning
• Face-to-face discussions, whiteboards discussions and overview diagrams are more effective for communicating with stakeholders than teleconference calls, email and detailed documentation
• Co-located projects teams are typically more successful than those who are far-located
• Very few teams like writing detailed documentation!

Earned-Value and Burn Charts

See: http://alistair.cockburn.us/Earned-value+and+burn+charts

Software Evaluation, Selection and Procurement Process

Typical example of a Software Evaluation & Selection Study:

• Build business case for investment including business and technical requirements and consideration of relevant opportunity costs
• Investigate alternatives including continued use of any existing products
• Investigate the services and support offered by the suppliers
• Investigate the financial viability of the suppliers
• Evaluate the products to confirm their fit to the business requirements
• Evaluate the products ability to fit into the organisations environment including ease of use, required knowledge for use, etc.
• Evaluate existing use of the product within similar organisations and/or negotiate setup of a functional prototype
• Evaluate enhancements and ongoing growth of functionality for the products
• Investigate licensing strategies

Common problems and associated risks:

• Lack of user involvement - erosion of project support, increased user resistance
• Poorly defined business case - cost overruns due to poor planning, lack of business benefits, lack of ownership
• Incomplete or inaccurate requirements - inability to sufficiently evaluate the system, unplanned work to identify new requirements at a later date, incorporate additional functionality and perform additional testing, difficulties establishing project scope
• Insufficient testing - unidentified software gaps and integration issues
• Insufficient verification with external customers/suppliers - customer/supplier discontent, lost sales, lowered customer service , cost increases
• Insufficient due diligence of software vendor - poor support, lack of future functionality for upgrade/enhancement, increased TCO

See: http://www.technologyevaluation.com/

Capturing Non Functional Requirements and Constraints

How should we capture requirements and constraints that typically cross-cut functional requirements? For example accuracy, availability, concurrency, consumability (a superset of usability), environmental/green concerns, internationalization, operations issues, performance, regulatory concerns, reliability, security, serviceability, support, and timeliness.

• high-level functional requirements should be identified within the initial requirements envisioning
  
• capture the details on a JIT basis throughout construction via short model storming sessions with stakeholders
• in addition to confirmatory testing to validate that you've built the system to your understanding of the requirements, an independant team should test a working build of the system on a regular basis from a higher level and attempt to break the system

Reference: Beyond Functional Requirements On Agile Projects

Preproject Portfolio Management

The preproject political maneuvering whereby an organisation must choose wisely between the many opportunities in which to invest their limited resources in order to maximise stakeholder ROI.

Four feasibility issues to consider:

• Economic - does it make sense from a business point of view
• Technical - technical capability and availability of skills
• Operational - are you capable of keeping the system running
• Political - will the system be tolerated and the changes it will engender

See: Iteration Negative One

Agile Scope Management

It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change. —Charles Darwin, The Origin of Species

"Plan-driven approaches work hard to prevent changes in scope, whereas agile approaches expect and embrace scope change. The agile strategy is to fix resources and schedule, and then work to implement the highest value features as defined by the customer. Thus, the scope remains flexible. This is in contrast to a typical waterfall approach where features (scope) are first defined in detail, driving the cost and schedule estimates. Agile has simply flipped the triangle."

There are five levels of planning common to most agile projects:

Vision

• The vision is defined and presented at a high level and not clarified until further discussions and subsequent exercises take place
  
• The vision presents the big picture to get all team members on the same page, defines the mission of the project team and the boundaries within which they will work
• The project's goal should be directly traceable to a corporate strategic objective
• Commonly only a dozen or so features may be identified e. "provide online order capabilities," "enable international ordering and delivery," "create data warehouse of customer orders to use for marketing purposes," and "integrate with our current brick-and-mortar inventory system."
  

Roadmap

• A roadmap is a high-level representation of how the product will evolve over time through subsequent releases e.g. the features or themes for each release, the customer targeted, the architecture and the business value
• The roadmap should be revised and developer on a regular basis
• The customer should own the the roadmap as they are responsible for maintaining and prioritising the backlog of work
• Feedback should be encouraged at all sessions to better define a reasonable approach to deliverables
• The end result of the vision and roadmap discussions should be the prioritised product backlog

Release Planning

• Review the strategies and vision and determine how to map the work from the prioritised backlog into the iterations that make up a release
• The release plan is divided up into iterations with associated high-level features
• The release plan also includes any assumptions, dependencies, constraints, decisions made, concerns, risks, or other issues that may affect the release
• Teams that are not co-located should make every effort to bring everyone together for this meeting

Iteration Planning

• At this stage features should be elaborated, tasks identified, and the time needed to accomplish the tasks estimated
• An iteration planning meeting should be used to conduct this work at the beginining of each iteration where the team reviews the release plan and the prioritised items in the backlog, reviews the features requested for the current iteration, and tasks out and estimates those features
• Here that the details of the features are discussed and negotiated and it's often discovered during that the sum of the task efforts exceeds the size of the iteration timebox therefore some of the work needs to be shifted either into the next iteration or back into the backlog

Source: The Software Project Manager's Bridge to Agility: Scope Management

Collaboration and Creativity

"Most software applications are written to solve a particular problem, so the typical IT project is task-based and operates in the upper half of the figure above. Projects that develop software tools and others that have similar profiles, however, work in a different way. Typically an individual or small group invests creative effort to develop the core ideas behind the tool. Once various approaches have been explored and one settled upon, the project shifts to a collaborative mode where a team builds the product."

Collaborative efforts succeed because of several contributing factors. Some of the most important are:

• Clear identification of the tasks and the team members assigned to complete the tasks
• Awareness of the team members' activities and progress and the overall progress of the project towards completion
• Rich history that offers views of the state of the project at any time in the past
• Effective synchronous and asynchronous communication

Source: Collaboration support: The next evolutionary step

Effective Meeting Communication

Here are some key points to remember for effective project meetings / discussions:

• Use of RDP / VNC to demonstrate applications remotely
• An issues list is maintained on a laptop connected to a projector so everyone can see what is being recorded

See: I want to know what you mean. What you meant. What you will mean. Everytime.

Fixed-Price Software Development

It is ok to fix the price, but there are many inherent risks with agreeing a "precise" scope and schedule at the beginning of a project:

• reduced flexibility of both the customer and the IT provider
• estimations for IT projects are hardly ever realised
• software estimation techniques vary dramatically and are unreliable
• the skills of those involved vary significantly for different projects and organisations
• it is difficult to rely upon historical data when technologies are changing all the time
• up-front estimation motivates Big Requirements Up Front (BRUF)
  
• a strict scope restricts changes to requirements which may hinder getting what the customer actually needs
• time and effort is wasted on overly precise up-front estimating

Traditionally we've wanted to believe in the concept that "software engineering" is 80 percent science and 20 percent art, but in practice development has proven to be closer to 20 percent science and 80 percent art. Or perhaps the 20 percent of software engineering that is art is simply 16 times harder than the 80 percent that is science.

Source: Is Fixed-Price Software Development Unethical?

Warning Signs of Project Failure

"When IT projects fail it rarely is a result of the technology. At its core, project management is all about people. It all has to do with project planning and early stages of analysis that companies like to jump over."

1. Undefined or poorly defined project requirements
2. Lack of project planning
3. Lack of or poorly developed budget forecast
4. Lack of stakeholder involvement
5. Lack of executive support
6. Frequent or large changes to project scope
7. Lack of change management process
8. Failure to establish appropriate client/user expectations
9. Unrealistic deadlines
10. Insufficient resources
    

See: 10 Warning Signs of Project Failure

ITIL (Information Technology Infrastructure Library)

ITIL v3 comprises 5 key volumes:

Strategy

• A framework to build best practice in developing a long term service strategy
• Includes general strategy, competition and market space, service provider types, service management as a strategic asset, organization design and development, key process activities, financial management, service portfolio management, demand management, and key roles and responsibilities of staff engaging in service strategy

Design

• The design of IT services conforming to best practice, and including design of architecture, processes, policies, documentation, and allowing for future business requirements
• Includes topics such as Service Design Package (SDP), Service catalog management, Service Level management, designing for capacity management, IT service continuity, Information Security, supplier management, and key roles and responsibilities for staff engaging in service design

Transition

• Relates to the delivery of services required by the business into live\operational use, and often encompasses the "project" side of IT rather than "BAU" (Business As Usual)
  
• Includes Asset and Configuration Management, Transition Planning and Support, Release and deployment management, Change Management, Knowledge Management, as well as the key roles of staff engaging in Service Transition

Operation

• Best practice for achieving the delivery of agreed levels of services both to end-users and the customers
• Includes balancing conflicting goals (e.g. reliability v cost etc), Event management, incident management, problem management, event fulfillment, asset management, service desk, technical and application management, as well as key roles and responsibilities for staff engaging in Service Operation
  

Continual Improvement (CSI)

• Aligning and realigning IT services to changing business needs (because standstill implies decline) by identifying and implementing improvements to the IT services that support the Business Processes
• The perspective of CSI on improvement is the business perspective of service quality, even though CSI aims to improve process effectiveness, efficiency and cost effectiveness of the IT processes through the whole lifecycle. In order to manage improvement, CSI should clearly define what should be controlled and measured. CSI needs to be treated just like any other service practice. There needs to be upfront planning, training and awareness, ongoing scheduling, roles created, ownership assigned,and activities identified in order to be successful. CSI must be planned and scheduled as process with defined activities, inputs, outputs, roles and reporting

See: The Official ITIL Website

Continuous Integration and Refactoring

A common question is how do you find the code that should be refactored?

Often refactoring takes place when making small changes to existing code while introducing new code or changing a method, but code which could benefit from refactoring can also be found by using static analysis tools. The following are examples of typical problems:

Conditional Cyclomatic Complexity

• Cyclomatic Complexity Numbers (CCN) measure the number of unique paths in a method via conditional constructs such as if and switch statements, while and for loops and exceptions
• Overly complex methods typically have a CCN of 10 or more
• Conditional statements can be refactored out using polymorphism

Duplicate Code

• Duplicate code often appears because it is sometimes easier to copy and paste code than generalise behaviour in another class, however this results in duplicate maintenance and inconsistent behaviour where there are slight variations
• Duplicate code can be found where a number of lines are repeated either exactly the same or similarly
• It can be refactored from a large method into an abstract class method

Long Methods and Large Classes

• There is often a correlation between long methods and conditional complexity and it is likely that the more lines in a method the more difficult it is to maintain the code
• Long methods should be extracted out into smaller reusable methods

Too Many Imports

• A class with many imports relies upon many other classes
• Fan out complexity can be used to find out how many classes a class depends upon

There are many static analysis tools available including CheckStyle and PMD. These tools can be included along with Unit tests as part of Continuous Integration (CI) builds triggered with every change to a project's version-control repository and by schedule.

See: Automation for the people: Continual refactoring