Project Management | Jimali Software Engineering

12 December, 2006 - 19:05 — GeoffGlasson

Articles

Title	Author(s)	Notes
10 things you should do near the end of a project	Bill Stronge	This article lists 10 things that a project manager should ensure are done before the project completes. Finalise testing; Finalise training; Validate deliverables; Get project signoff; Release the team; Analyse actual vs. planned; Archive documentation; Ensure contract closure; Conduct a postmortem meeting; Perform a self assessment;
10 things you should do near the end of a project	Bill Stronge	This article suggests actions that should be completed at the end of the project.
10 ways to avoid stupid project estimates	Jerry Loza	This article gives some tips on preventing bad estimates and improving estimates. The takeaways are: Let history be your guide; Ask for details (proof); Challenge the numbers; Measure; Bracket the work; Get a second opinion; Remember that two heads are better than one; Give feedback; Reward and penalise; Develop a culture; There is some very good advice in this article. It's well worth reading.
10 ways to get a slipping project back on track	Tom Mochal	This article gives several tips for rescuing a slipping project that may work for your project. This list of tip is: Work overtime; Reallocate resources; Double-check all dependencies; Check time-constrained activities; Swap resources; Crash the schedule; Fast track it; Prevent all scope change; Improve processes; Scale back the scope of work; Tips aren't guaranteed to work in all (or any) cases but they may help. The article is worth reading and thinking about if the project is slipping.
11 ‘Laws of IT Physics’	Michael Krigsman	During testimony before Congress, Norm V. Brown presented what he calls “Laws of IT Physics.” These “Laws” highlight hidden pitfalls the hurt many projects and help explain why some projects succeed while others fail. (from article)
6 essential elements for a winning business case	Ilya Bogorad	This article provides guidance for writing a business case. It also includes a link to a template that can be used as a point of reference.
A systematic approach in managing post-deployment system changes	David Kang, Roger Chiang
Agile Fixed Price Projects Part 1: "The Price Is Right"	Cauwenberghe, Pascal Van	This article discusses using Agile methods on fixed price projects. It poses a number of questions that should be asked prior to bidding for fixed price work, and describes a number of strategies to aid in the completion of the project. This is part 1 of a two part article .
Agile Fixed Price Projects Part 2: "Do you want agility with that?"	Cauwenberghe, Pascal Van	This follow-up article discusses how Agile methods can be applied to a fixed price contract. It seems to be a pragmatic application of Agile methods that have been adapted as necessary to work within the fixed price project environment.
An earned value tracking system for self-directed software teams	Steven H Lett	Firefox Noscript users: You need to allow this site to execute scripts so that it can display the article.
Consolidate all project management deliverables in the project plan	Tom Mochal	A project plan is the name given to all of the project management documents used during the project. Find out the specifics of what the project plan entails. (from article)
Create a risk contingency budget using Expected Monetary Value	Tom Mochal	Tom Mochal describes a mechanism for allocating risk contingency budget that can be used in the event of a risk occurring.
Denver International Airport Automated Bagges System	Daniel Stearns	By all accounts Denver International Airport's automated baggage handling system was a disastrous project that was very late and very much over budget. There were numerous software and hardware problems with the project, but essentially it appears to be a risk management failure. The contractor and the client appear to have spent insufficient time and energy on identifying project risks which in turn meant that they couldn't be addressed. Had more time been spent on risk management the outcome might have been different. More information can be found in Tom DeMarco's book Waltzing with bears.
Design by Contract: The Lessons of Ariane	Jean-Marc Jézéquel, Bertrand Meyer	This case study is about a software failure that caused the Arianne 5 rocket to destroy itself on its maiden flight. This was a failure caused by software re-use. ESA's accident report is also available.
Development Practices for Small Software Applications	Capers Jones	This article compares the use of Agile methods with CMM/CMMI on small projects. The author shows that there are some advantages to using Agile methods in small projects; but also shows that CMM/CMMI can be used to deliver effective results but at a (typically) greater cost. He recommends using CMM/CMMI for larger projects. He also shows that some organisations have had success integrating Agile methods into formal methods such as Six Sigma.
Don’t wait to address performance problems on a project	Tom Mochal	This article discusses why we shouldn't wait to address personnel performance problems on a project, and suggests an approach to dealing with it.
Earned Schedule: A Breakthrough Extension to Earned Value Theory? A Retrospective Analysis of Real Project Data	Kym Henderson	This is a case study using Earned Schedule reporting alongside EVM.
Earned Value Management Implementation Guide	Unknown
Earned Value Management: Are Expectations Too High?	Nanette Patton, Allan Shechet
Earned Value Project Management - A Powerful Tool for Software Projects	Quentin W. Fleming, Joel M. Koppelman	This article discusses 10 things that a project manager must implement in order for EVM to be of value to them. These are: Define Work Scope Create an Integrated Bottom-Up Plan Formally Schedule CAPs Assign Each CAP to an Executive for Performance Establish a Baseline that Summarizes CAPs Measure Performance Against Schedule Measure Cost Efficiency Against the Costs Incurred Forecast Final Costs Based on Performance Manage Remaining Work Manage Baseline Changes
Ensure requirements are tracked throughout a project	Tom Mochal	This article discusses the need for tracking requirements during a project to ensure that they are implement. A simple traceability matrix is described.
Establishing a Project Management Office	TechRepublic
Evolving the Project Management Office: A Competency Continuum	Gerard M. Hill
Five steps to enlightened expectations for managing your workload	Chip Camden	This article discusses ways of setting your expectations of the amount of work you can do in a day, and suggests ways to make it happen.
Five tips for building a Work Breakdown Structure	Tom Mochal	This article gives some good tips on setting up and using a WBS
Get everyone on the same page with a project kickoff meeting	Tom Mochal	This blog entry talks about the importance of holding a project kickoff meeting for every project, even if the project has already started. It gives tips on what topics should be discussed.
If EVM is so Good - Why isn't it used on all projects?	Quentin W. Fleming, Joel M. Koppelman	This article presents reasons why EVM isn't used on all projects.
Improving Implementation: Organisational Change and Project Management	John Wanna	Background The papers included in this collection were presented at the Project Management and Organisational Change conference held in Canberra in February 2006. This was the first annual research conference organised by the Australia and New Zealand School of Government in conjunction with the Department of the Prime Minister and Cabinet. The conference provided a platform for over 50 speakers and attracted over 350 attendees across the two days. Speakers included top public sector executives from the Australian jurisdictions as well as representatives from the United Kingdom, Canada and New Zealand. (from document). Contributors Lynelle Briggs, Australian Public Service Commissioner Karen Baehler, School of Government, Victoria University of Wellington Department of Finance and Administration, Australian Government Christina Gillies, Non Executive Director and IT Governance Consultant Peter Hamburger, Department of the Prime Minister and Cabinet Evert Lindquist, School of Public Administration, University of Victoria, Canada Kathleen Kuryl, Manager Better Practice & Project Services, Department of Premier and Cabinet, Tasmania Ian McPhee, Auditor-General for the Commonwealth of Australia Ian Glenday, Executive Director, Office of Government Commerce, London Scott Prasser, Faculty of Business, University of Sunshine Coast Abul Rizvi, Department of Immigration and Multicultural Affairs Patricia Scott, Secretary, Department of Human Services Wayne Sharpe, Executive Manager, Gateway Unit, Department of Treasury and Finance, Victoria Peter Shergold, Secretary, Department of the Prime Minister and Cabinet Anne Tiernan, Centre for Governance and Public Policy, Griffith University Dennis Trewin, Australian Statistician, Australian Bureau of Statistics Jim Varghese, Director-General, Department of Primary Industries and Fisheries, Queensland John Wanna, Sir John Bunting Chair of Public Administration, ANZSOG/ANU Bob Webb, Deputy Commissioner, Australian Taxation Office Raymond C Young, Department of Accounting and Finance, Macquarie University
Kate Oneal: Funding Susan’s Projects	Ron Jeffries	This is a "canned" story about two people sitting down to discuss project opportunities, their costs, and their priorities. I think this is a good illustration of a method of working with the customer to determine the relative priorities of several "must have" projects. I think the approach is sound even if the story appears to be fabricated.
Knowledge: The Core Problem of Project Failure	Timothy K. Perkins	This article argues that project fail due to two main reasons: lack of knowledge by the Project Manager, and the Project Manager failing to use the knowledge they have. I think the argument has merit and is something to watch out for in our projects. The article is worth a read.
Making Agile Development Work in a Government Contracting Environment	Glen B. Alleman, Michael Henderson	This article discusses the use of EVM on XP-like projects. This could be applicable to many types of projects, especially those that operate in tradition project management environments. The article demonstrates that earned value can be used to show the velocity of the project team by using a fine grained data collection.
Master these 10 processes to sharpen your project management skills	Tom Mochal	This article discusses the 10 primary processes that a PM should use when managing a project with links to supporting documents.
No Silver Bullet: Essence and Accidents of Software Engineering	Brooks, Frederick P.	Frederick Brooks' classic article about why there are no silver bullets in Software Engineering. An interesting point raised is - The hard thing about building software is deciding what one wants to say, not saying it.. In many respects, this quote neatly describes the biggest obstacle to software system delivery - delivering the right thing whilst managing the expectations of the customer and the project team.
Opinion: Before you kill that project ...	Bart Perkins	This opinion piece outlines some of the issues that need to be considered when terminating a failed project. The key points from the article are: Political fallout; Associated expenses; Unexpected behavior; Supplier relationships; Lost business opportunity; Morale; Media coverage; This is an interesting article and worth reading.
Project management responsibility can be elusive	Tim Malone	The author discusses some of the lessons he learned from not communicating sufficiently with non-technical project managers and customers. Learning how to communicate with non-technical people is a art in itself, one that will take a long time to learn.
Respect the processes you put into place	Ramon Padilla	This blog discusses the importance of respecting the processes that are put in place in order to prevent them becoming a millstone around the necks of the people who have to use them. Padilla talks about managers (in particular) who define specific processes but who then either ignore the process or make it impossible for people to use the process. An interesting read and food for thought.
Schedule Adherence: A Useful Measure for Project Management	Walt Lipke	This article discusses the use of Earned Schedule as a mechanism for showing how a project is progressing against its baseline.
Schedule is different	Walt Lipke	This article describes a method for managing and reporting project schedules in a meaningful way. It describes that the traditional use of schedule variance within the Earned Value Method (EVM) does not paint an accurate picture of the state of the projects' schedule in relation to it's planned schedule. Lipke proposes the Earned Schedule extension to EVM to assist project managers understand how the schedule is progressing against the baseline plan.
Six secrets to productivity and getting tasks completed	Chip Camden	This article is a follow up to Five steps to enlightened expectations for managing your workload, and describes some techniques for improving your productivity.
Social and Technical Reasons for Software Project Failures	Capers Jones	This article looks at social and technical reasons why software project fail. In particular, it looks at the following: Root causes of inaccurate estimating and schedule planning; Root causes of incorrect and optimistic status reporting; Root causes of unrealistic schedule pressures; Root causes of new and changing requirements during development; Root causes of inadequate quality control; This is quite a good article and definitely worth keeping in mind when planning and executing a project.
Software Project and Process Measurement	Christof Ebert	This article discusses measuring project processes to improve performance on the current and future projects. The article suggests asking questions such as: What should I do?; What should I look at?; Are we doing a good or bad job?; Are we doing better or worse than in the last period?; What can we realistically achieve in a given period?; What is the best way to achieve our targets?; Asking questions along those lines will help focus investigations and identify where measurements can be made. This is an interesting article and well worth reading.
Software Tracking: The Last Defense Against Failure	Capers Jones	This article looks at tracking software projects in order to prevent them failing. It discusses a number of reasons why software projects have failed, and why the customer has litigated. The article proposes a number of milestones that tracked, and suggests a format for monthly reporting. The information in this article is targeted at large projects; however I think the ideas and suggestions can be adapted for use within smaller projects.
Start With “Simple” Earned Value On All Your Projects	Quentin W. Fleming, Joel M. Koppelman	This article proposes that implementing Earned Value Management for a project is a 10 step process. This is relatively simple proposition that seems to have some merit.
Supervise larger projects with a schedule management plan	Tom Mochal	This article talks about the need for a Schedule Management plan to assist with managing large projects. The plan details when, why, what, how, and who can update the schedule and distribute information.
Ten Unmyths of Project Estimation	Phillip G. Armour	This article talks about 10 "unmyths" of software estimation. The unmyths are (from the article): End-Date: The job of estimating is to come up with a date for completion. Commitment: The estimate and the commitment are the same. Size: A project estimate is dependent on the size of the final system. History: Historical data is an accurate indicator of productivity. Productivity: Productivity is an accurate indicator of project duration. LOC: A Line of Code (LOC) count is a good way to size a system. Function Point: Function Points are a good way to size a system. More People: We can get the system faster, by assigning more resources. Defect-Free: Given enough time, we can create a defect-free system. Accuracy: We can have an “accurate estimate.”
The first step in building a schedule: the WBS	Tom Mochal
The politics of IT project estimations	Charles Seybold	This simple article contrasts two different methods of agreeing estimates with a stakeholder. One gives a fixed point in time, the other gives a time range with confidence values. The latter seems to be the better option, its a shame we don't use it often enough.
The top 4 things project managers do to destroy software quality	Robert Bogue	This article talks about the things that project managers do while trying to bring a project in on time and budget; but which are counter productive to software development and software quality.
The weaknesses of a technical project manager	Shannon Kalvar	This BLOG discusses how the technical strengths of technical project managers affect their ability to look at the bigger picture.
Three Ways of Expanding the Scrum Definition of “Done”	Mishkin Berteig	This article discusses having a standard definition of what "done" actually means when applied to individual features in a software development project. He promotes documenting the definition of "done" so that everyone understands what they mean by done. The author suggests that various milestones be added to the definition, and that once they have all been met the task can be considered to be done. Whilst this article is specific to software development, the principle applies elsewhere. We all use the term "done" to indicate that we believe we have completed an activity. Unfortunately the definition is often different between various people leading to differing expectations of how far the work has actually progressed. I wrote about this in The insanity of software testing as well.
Three tips for avoiding project estimating mistakes	Erik Eckel	This article suggests things that a project team can do to minimise the risk of producing incorrect cost and time estimates. The tips range from confirming all assumptions through to ensuring that everything is documented.
Use a Fishbone Diagram to attack complex problems	Tom Mochal	One technique for analyzing complex problems that appear to have many interrelated causes is called a “cause and effect” diagram or a Fishbone Diagram. Here are examples of how this problem-solving technique works. (from article).
Use a responsibility matrix to show who does what in your projects	Tom Mochal	This article talks about the use of a responsibility matrix to clarify the responsibilities of various project stakeholders. This is quite helpful, especially in scenarios where there are a number of people that must collaborate to complete one or more deliverables.
Use this process to estimate a project’s effort hours	Tom Mochal	Once you understand the effort that’s required for a project, you can assign resources to determine how long the project will take and estimate labor and non-labor costs. Here’s a process you can use to estimate the total effort required for your project. (from article)
Using Earned Value for Performance Measurement on Software Development Projects	David S. Christensen, Daniel V. Ferens	This article was written in 1995 when EVM was not widely used in software development projects. Whilst EVM is still not widely used in software projects, it is becoming more popular and aspects of this article are still relevant. The article provides a (very) brief introduction into the Earned Value Management method.
What’s so hard about sticking to the plan?	Shannon Kalvar	A blog about how managing risks often leads to difficulties sticking with the plan.
When to step in if employees are fighting	Ken Hardin	This article gives some tips on resolving conflicts between staff members.
Why Do I Need All That Process? I’m Only a Small Project	Mark Brodnik, Robyn Plouse, Terry Leip	This is a brief case study describing how Intel adopted its CMMI processes for large projects so that they could be used on smaller projects.

Source	Article	Notes & Comments
	You have been reprioritized!	Deals with project scheduling and monitoring of staff and other resources not directly under the control of the Project Manager.
	A systematic approach in managing post-deployment system changes	Describes how a bank developed a process for dealing with changes in a deployed system. The article looks at the lessons learned and how the bank adapted it's processes to deal with the change requests made by the systems' users.
	The operational executive sponsor	This article talks about the need for obtaining committment from senior management when making any type of process improvement. Most important of all is that the person actually be committed to the process rather than just paying it lip service because the people trying to implement the change will see right through it. The committment of doing what's right not what's expedient is critical to the success of these types of changes.
	Agile project management: steering from the edges	This article describes the changes that were implemented to a 120 person team that was behind schedule in order to improve morale, quality and delivery confidence.
	Planning and Running an XP Iteration (added 15-Aug-06)	Article describing the process that ThoughtWorks uses on project iterations. It has some interesting ideas that warrant further study.
	The Impact of Agile Methods on Software Project Management (added 21-Aug-06)	This article discusses various factors that influence the decision to use Agile Methods on a project.
	Use standard roles to avoid confusion on projects (added 29-Aug-06)	Discusses the importance of having standard roles for project team members.
	A Project Management Primer or "A Guide on How to Make Projects Work" Work" (added 29-Aug-06)	(from article) Many projects fail because of the simplest of causes. You don't have to be a genius to deliver a project on time, nor do you have to be steeped a mystical project management methodology to be a project manager. Project management can be a difficult and thankless task. When things go wrong you shoulder the blame and take responsibility. When things go right the credit goes to the team and rarely do you get singled out for a pat on the back. Yet projects come with astounding rewards. Astute business managers know that it is not the cleverest technical specialist or the smoothest talking salesman who adds real value to a business.
	The value of acknowledgment (added 29-Aug-06)	This blog entry talks about the importance of acknowledging the good work done by team members.
	To Learn Team-Building, Ask The Dirty Dozen (added 29-Aug-06)	This article suggests that the manner in which the team in the "Dirty Dozen" was put together is a template for how project teams should be led. It's an interesting suggestion.
	Mini-glossary: Project management terms you should know (added 01-Sep-06)
No logo	Extreme Programming Explained (added 20-Sep-06)	Transcript of an inteview with Kent Beck, Cynthia Andres, and Tom Demarco. Quite an interesting read because they discuss what they have seen people doing, as well as other things.
	Facilitating Earned Value Management and Knowledge Sharing Through the Web (added 07-Feb-07)	Discussion about using Earned Value methods.

Case Studies

These case studies show how various methods have been used by development teams. They are recorded here to stimulate discussion and thought rather than be taken as a blanket endorsement of the particular methodology used.

Title	Author(s)	Notes
Denver International Airport Automated Bagges System	Daniel Stearns	By all accounts Denver International Airport's automated baggage handling system was a disastrous project that was very late and very much over budget. There were numerous software and hardware problems with the project, but essentially it appears to be a risk management failure. The contractor and the client appear to have spent insufficient time and energy on identifying project risks which in turn meant that they couldn't be addressed. Had more time been spent on risk management the outcome might have been different. More information can be found in Tom DeMarco's book Waltzing with bears.
Design by Contract: The Lessons of Ariane	Jean-Marc Jézéquel, Bertrand Meyer	This case study is about a software failure that caused the Arianne 5 rocket to destroy itself on its maiden flight. This was a failure caused by software re-use. ESA's accident report is also available.
Development Practices for Small Software Applications	Capers Jones	This article compares the use of Agile methods with CMM/CMMI on small projects. The author shows that there are some advantages to using Agile methods in small projects; but also shows that CMM/CMMI can be used to deliver effective results but at a (typically) greater cost. He recommends using CMM/CMMI for larger projects. He also shows that some organisations have had success integrating Agile methods into formal methods such as Six Sigma.
Why Do I Need All That Process? I’m Only a Small Project	Mark Brodnik, Robyn Plouse, Terry Leip	This is a brief case study describing how Intel adopted its CMMI processes for large projects so that they could be used on smaller projects.

Source	Study	Notes & Comments
No image	Refactoring the development process	Study of three companies. One failed miserably, the other two had problems but eventually got there. Getting people involved in the process of making decisions seems to be the key.
	Using XP in a Big Process Company	Study of how eXtreme Programming methods were introduced into a company that produced safety critical software
	Managerial IT unconsciousness	Discusses the failure of three high profile Australian IT projects. The root cause of the failures seems to be governance failures. The projects were at RMIT, Sydney Water, and One.Tel.
	Defining and contributing to software development success (added 15-Aug-06)	Study looking at how developers see project success. The research indicates that develoeprs measure success by whether they've delivered a system that the client wants to use not just one that meets the specified (contractual) requirements.

Project Management

Jimali Software Engineering

Navigation

Articles

Case Studies