Freigeben über

Case study: create and use Platform Goals to reduce churn

  • Artikel

If you find yourself in the unenviable position of having to prove to someone that your project is being managed correctly, look to your 'platform goals'.  Don't have 'platform goals?'  Don't know what they are?  You are not alone.

Platform goals are the statements of principle that describe How and Why you are building your project the way that you are... they are independent of "what" the project is (the project's functional and technical requirements) but are not independent of the business requirements.

For example: if you have always believed that it is important to deliver value, even if you cannot be perfect in the first iteration, and you run your projects that way, you have created a platform goal.  You need to communicate it.

Also, if your project is building a system that only one team will use, for now, but you are building it for other teams to use, in the future, then you need to gather requirements in a different way, and take on different costs, than if you are building just for one customer.  You need a platform goal to describe this.

Working with some team mates of mine, we came up with some platform goals for the project I'm currently attached to.  The reason was to make sure that everyone saw not only What we were building, but How we were building it, and Why we were building it in this way.  We need to be public about this. 

For the sake of the project, I changed the names and processes.  In this blog post, we are building a system that allows the procurement department pick truck tires for the Contoso Trucking and Transportation Company.

Platform Goals for the Contoso Procurement Platform (CPP):

  • Enterprise: Designed to enable all procurement decisions for the enterprise, starting with truck tires
  •  Agile: Designed for iterative releases over time, with first release occurring in February of 2007
  • Focused: Scope limited to the generation and acceptance of procurement agreements that can be executed by downstream systems
  •  Inexpensive: Minimize cost to operate on a per-agreement basis (process, operating, and support overhead)
  •  Adaptable: Designed to cope with a radically changing IT landscape with respect to upstream and downstream systems, including the new asset management and financial tracking systems.
  •  Integrated: Intended to provide shared data and functional services to other systems that need similar capabilities
  • Strategic: Intended to allow and enable the decommissioning of one or more legacy systems including the "general procurement desk (GPD)" system.
  •  Empowering: Able to readily deliver the needs of new procurement efforts with minimal refactoring, redevelopment cost, or IT resources

By describing the goals in this way, we can counter criticism that may say: why didn't you collect 100% of the enterprise requirements up front (which in some corporations is an invitation to analysis paralysis) or why doesn't this system also handle shipping and receiving (which in most places is an invitation to permanent scope creep).

There are a lot of good ideas about the right way to run a project. This statement says "These are the ideas we are using." It says that if you want to challenge the project, you have to first challege this set of ideas. 

That is harder to do. 

As such, you may just get away with reducing some of the churn that happens when projects are inspected, reorganized, and, in some cases, killed, not because the project is failing to deliver or delivering an unusable system, but because someone disagrees with the processes you use, or has a political bone to pick with your manager. 

Inspection is healthy. Churning is not.

Comments