08 March, 2011

Project management tip for the day

Just finished a review of a proposed project. The usual things: cost, schedule, resources, risk, technical objectives, fit with tactical and strategic objectives...

One thought popped out that I want to share with this community:

Plan the project staffing based on the work that needs to get done. Don't plan (and size) the work to be done based on the staff you have on hand.

What I encountered was what I thought to be a one person stress analysis task but three stress analysts proposed to be working the project. The rationale given to me was, "Well, I need to cover these other two, so I stuck em in here."

That is a very human and humane impulse, but if we pad our work like that, soon enough everyone will be out of a job. I asked the team to find legitimate options for the other two analysts to work on other projects, and after a few phone calls, we found some no-kidding-around useful tasks for them, and in fact brought help to a project that was in danger of falling behind schedule.

Charlie Sheen notwithstanding, I will declare, WIN-WIN!


Loss of NASA Glory climate satellite

Last week NASA's Glory atmospheric observation satellite was lost in a launch incident. So what does this mean for commercial space flight? Probably not much.

07 March, 2011

Inaugural post to this blog - Requirements 101

For maximum "auspiciousness", I'm typing these words at the stroke of midnight. Anyway, I want to welcome anyone with the temerity to find this post. What I plan to comment on and make note of (over time,; not all tonight!) are some common lessons learned in my systems integration work for various clients in different industries.

Originally, systems integration seemed to be the almost exclusive domain of heavy duty, capital-intensive programs in aerospace and defense. The Polaris and Minuteman missile systems come to mind. But if you look for it, you'll find (or at least will be painfully aware of its absence) the fundamental systems engineering & integration discipline across the board in projects large and not so large. So the bottom line is we've been at this for quite a long time and a reasonable person might expect that we're pretty good at it by now.

Well, I don't see that to be true. Just last week I was confronted with an ever expanding set of requirements for a back-up gas turbine powered electrical generator set. Some of these struck my as being pretty ad hoc and nebulous. In the interest of diplomacy (peace and harmony is in very short supply in this world lately), I thought to approach my concerns with my client a bit obliquely. Rather than jump into a debate/monologue about parent/child/orphan requirements (which we can talk about here in more length at a future time if comments indicate any interest exists), I asked a very simple question. Pointing to one requirement statement, I asked, "And how should we be looking to verify that we've satisfied this one?" Without much hemming and hawing even, the conclusion was that the requirement was impossible to verify in sort of a objective, quantitative sense. And here is the lesson learned for this evening:

If a requirement can't be verified by any of the usual and customary methods; i.e., inspection, test, demonstration or similarity, then really by definition it is not a true requirement. So, if we run into a "desirement" like, "The generator set shall spring to life with an authoritative yet mellow roar that reinforces the self esteem of the entire operating shift", we know some remedial work is in order.

A handy method I enforce to force the issue with such counterfeit requirements is to have everyone use an Excel spreadsheet as a pre-screen/entry form. It has fields for the requirement title and description, whether it is a parent or child, if it is explicit or derived, and what the proposed verification method is. The notes field can even capture pass/fail criteria if one is in a position for that sought of foresight. If you can't answer those questions pretty succinctly, reassess your requirement. Don't be surprised to discover that it's not a requirement at all, or perhaps is two, or three, or five rolled into one.

Failure to invest time to get the requirements picture straight, well documented, and agreed to by all the pertinent stakeholders is a prescription for long-term suffering, disappointed and angry customers, big cost surprises, bigger award fee shortfalls, and a bad reputation.

This is yet another systems integration task where doing it "the hard way" is really the easiest way to get the job done.

Tomorrow, I'll comment on the impact of the loss of NASA's Glory satellite due to a problem with the Orbital Sciences booster system on the overall status of commercial spaceflight.

A good night to all.