Dave's random mumblings…

My father has talked about British sovereignty being given to Brussels over the last 35 years, and to some degree he’s correct. A series of treaties that have built upon each other, together these have given the European Parliament some significant powers in limited areas.

The next stepping stone was the Treaty of Lisbon, it created two posts that would be the EU equivalent of President and Foreign Secretary. These two appointments were in part designed to give the EU more of a “face” and give foreign diplomats and ministers someone to call instead of being forced into the maze of EU departments.

The appointment of two rather minor figures to these posts says an awful lot of how the 27 members of the EU see the role of the parliament and council.

These roles were being sold at one point as big posts with real power, have been filled by the Belgium center-right Prime minister and a Labour Party stalwart with zero experience running foreign affairs.

Not exactly figures that will be giving other heads of state sleepless nights. It is not just that the national leaders do not want a high profile rival, as Tony Blair would have been had he got the job. It also shows that the EU is far from a coherent political entity and to be fair it seems that some members do not want it to be.

The Union has accomplished many good things. It has tied everyone to each other and ended conflict in Europe, it has certainly led to growth and prosperity. It runs a single market, eliminated border controls and keeps playing fields between members level. However it seems its members are not quite ready to stand back while Brussels and Strasbourg based diplomats took over running the community.

The appointments show that the members were not ready to make Lisbon another step towards a United States of Europe. It is a small shuffle forward, but no more than that.

Incidentally the new president of Europe once said “Turkey is not a part of Europe and will never be part of Europe”. “The universal values which are in force in Europe, and which are fundamental values of Christianity, will lose vigour with the entry of a large Islamic country such as Turkey.”

In contrast to Toyotas and their often vague, but challenging goals NASA uses a very different requirement process.

They break the goal setting into four distinct actions before authorizing a project.

Need – every requirement for a program or project should be fully understood and how this requirement is needed to fulfil he project goal. The idea is clearly to stop unnecessary items (or work statement padding) before it starts. NASA feels each initial requirement should be examined as closely as any change coming through a robust change management process.

Attainable – If the project goal is unattainable with the assigned project resources then the project is a waste of time and effort. There may a need for feasibility studies, technology demonstrators to prove concepts or firm up what started as an educated guess. These risk reduction activities need to be part of the project plan and the results of which may drive gate decisions.

Verifiable – Each requirement needs to be examined closely and clear criteria included in how it will be verified. There should be clear pass/no pass criteria that are not subjective and therefore unverifiable.

Accountability – This is seen as important for each individual requirement and ownership of each requirement should appear on the charter or requirements document. NASA feels the owner should be a person with a stake in, be knowledgeable about, and understand how success will be measured for each requirement. The owner needs to be involved in all change managmenent activity that affect their requirements.

NASA, like the rest of aerospace, works extensively with specifications as a risk reduction strategy. A specification control document identifies the final functionality, environmental quality, foot print, interface and so on of the final product. Be it a complete launch vehicle or a small component of that launch vehicle.

The accuracy of a specification is every bit as import as any other requirement document.

This contrasts with Toyotas approach where goals are purposely left rather vague to encourage organizations to explore options and encourage groups to collaborate with others (both internally and externally) to find the best solution.

In a far more risk adverse industry the goals are very clearly stated and the way in which they will be met is left open a little more.

It’s an interesting contrast in style.

Just took part as a non-advocate review of after action review for a pure development engineering project that a friend of mine is delivering this afternoon. My projects have typically impacted operations and the factory, I don’t see development projects very often and it was fun to look at something new and be a neutral in the room reviewing the material I don’t have to deliver.

I noticed a few major differences in approach that may have value for my projects in the future.

Identify the primary requirements, in the example today that was three aspects of the deliverable, these were frozen and were off limits to change unless the revision was essential and had been through a formal process of reviews and approvals. I liked this, managing change is always an issue that takes inordinate amounts of time. While putting certain aspects of the deliverable out of bounds does require additional work during the define and charter phase, over the course of the project it pays dividends over the life of a project.

Integrating the concept of “fit, form, function, interchangeability and safety” into the change management process. I spent many years as a manufacturing engineer in a part number controlled world where revising any of the above requires a part number roll (-1 to -2). For production projects if a change in the deliverable (process, flow or physical part) casuses any changes to fit, form, function, interchangeability or safety then the project charter must be rolled to reflect the new “part number”.

Finally the deliverable was defined in the charter not only by physical properties and functionality, but also in how they would be inspected and measured. This avoids problems where an item passes shipping inspection, but is held for receiving inspection because of drawing interpretation or methodology. For a deliverables that reduces flow time, this would require the flow reduction measurement (touch time, wait time, end-to-end flow time or batch size) methodology to be agreed upon and documented up front.

The biggest takeaway was reinforcement of what I already believe; it all comes down to a watertight charter as the base the project is built on, no matter what the deliverable. Again I see a couple of new ways to really make it more comprehensive with out huge amounts of additional time being added to the charting process.

I enjoy taking part in looking at projects outside my usual realm. I typically get to look at something new or cool, and that makes my inner geek happy, but I also get to see how other organizations do things differently, see better ways of doing something and pick up new ideas to help my own projects.

Every project is driven by a requirement of some sort, the hard part is translating that business requirement into an end product that fully meets that business need.

My back ground is manufacturing, manufacturing tends to be a series of iterative steps that lead you to a product that fulfills the requirement. I try carry the same iterative approach to my project chartering.

Sitting in a meeting listeing to the sponsor tell you, in detail, what they want the project to achieve is easy. I have found time and time again that what the project team hears and starts working towards is not what the sponsor meant.

When the project only delivers part of what they customer wants (and thought they were paying for) there is typically plenty of blame to go around.

By the time the team, sponsor and whoever else is involved has discussed, reviewed, feedback and finally gained clarity as to exactly what the deliverable is and written the charter we have defined the following:-

Business requirements. All detailed requirements should be based on clear business needs. This comes from and executive sponsor, manager or someone with a very clear understanding of the project and the value it will provide to the customers

Scope. In my opinion the most critical part of the charter. It’s not only what will be included in the proposed solution, but also what will not be part of the project. It establishes exactly what the scope and limitations of the deliverable is so the various stakeholders (and the team) have an agreed upon standard against which they can evaluate the final product. Once agreed upon this is the baseline which the change management process starts with.

Context. Any business issues related to the project need to be clarified. Assumptions, priorities and ground rules need to be clearly stated.

Vision. A long-term vision for the new system and the need it will fulfil both when the project is complete, and into the future further along the product lifecycle.

One of the common issues this stage identifies is that the two groups (sponsor and project team) are not speaking the same language. Typically not everyone has a deep technical understanding or intimate knowledge of the process. If the scope contains too much technical language then the business requirements that we are trying to fulfill may become dilute or lost. This is why the business requirements should be part of the top level project document.

This step is all about reducing risk to the project and the project team. Taking a very thorough approach during the charter stage of the project, the PM greatly reduces the risk to the project, the project manager and the stakeholders.

By clearly documenting the project’s vision and scope in writing, and fully clarifying all requirements we create a proposal that will meet the business need, contain costs, and reduce the risk of failure.