Signing Out from INCOSE 2008

Well, I hate to say it, but my week here at INCOSE 2008 has come to an end. And though I must say goodbye to my INCOSE friends, I'm not headed home quite yet - first I will enjoy a few days in Amsterdam, just up the road from Utrecht.


A few final comments from this side of the pond (some of these are purposefully non-INCOSE related to keep it interesting!):

• After hours of listening to talks about process, I have to say - systems engineering processes are heavy! There are images dancing in my head of things like a project plan circle diagram that even in a 3x3 foot printout, you have to squint to read the tasks. Or there are the matrices that don't even come close to fitting on a page, yet they try to squeeze them in for demonstration of a concept.
• I spoke with some systems engineers who, when I explained what Seilevel does, said things like "Really? Requirements as a job?" or "You have a business around that?" or "I never thought of them as a separate thing, they were just some other task on my project that maybe got done." or my favorite "Why are you at a systems engineering conference then?"
• It's a small world. In a city of more than a million, today I ran into a fellow INCOSE member from San Antonio, TX on my way back from the Rijksmuseum.
• Most all of the presenters like to use words on slides! Seriously, I almost think it must have been in the presentation requirements - "Must have wordy slides". Perhaps I can suggest Beyond Bullet Points.
• I enjoyed reconnecting with my friends from what I like to call "Seilevel Europe", the HOOD Group (and mind you, they would and should probably call us "HOOD Group USA"). We have very similar companies, with similar methodologies, in different parts of the world. If you haven't heard of them, I encourage you to take a look at their work.
• Sadly, Holland just lost in the quarter finals of the Euro 2008. I say sadly because I've actually become quite fond of watching the "Oranje" games (or maybe just the crowds hanging outside of bars).
• I once again was reminded that so many Americans have a tendancy to focus on just us. This is by no means a generalization though. I personally like to intermix with those from other countries, though I'm also quite guilty of speaking American and little else. Anyway, it was frustrating to listen to talks from Americans who would only quote American statistics, or American events, or American disasters. My European friends were quick to point it out for me "Oh another American talk!". Thankfully some of the talks were very different than that though, making me much more proud.
• We should do more peer reviews, but not for the obvious reasons. A systems engineering organization requires team members to be on peer review boards, not so much for improving the quality of the deliverables, but more importantly, to expose the engineers to more projects and ideas that they can then apply to their own projects. Brilliant, I say!
• The field of systems engineering has many many many outstanding success stories, ranging from the Airbus 380 to the ProRail system of the Netherlands. There are lots of great lessons to be learned here that can be applied to much simpler projects. But really, how cool would it be to build a network of thousands of kilometers of rail or to put a new airplane in the air?

Anyway, in a few days, I will return home with many fond memories of the Netherlands and INCOSE 2008.

Get More Productivity Out Of Your Email

Have you ever received an email and all you could think was “Okay, so now what?”

Or, even worse, you go off and do some work in reaction to it and then find out the email was FYI, no action expected?

Unfortunately, I have. Both cases. And, I'm afraid to admit, I’ve probably sent a few emails that had the former reaction, if not the latter.

After a less than productive email exchange the other day, I remembered a guy I used to work with who had a hard and fast rule: “Before I send an email, I ask myself what action I expect the recipients to take, and make sure that it is clear.”

Good advice. It sounds so simple, so obvious. Yet, since a coworker and I both needed the reminder, I thought I’d share it.

I'm NOT Going to Read Your Requirements

Ever get the impression that your stakeholders simply aren't going to read the requirements documents you create? Better yet, have you ever had a stakeholder actually tell you directly that he or she just isn't going to read the requirements? I haven't, but I wish someone would. That sort of direct, honest communication would be a shock, but sometimes that's exactly what we need to shake ourselves out of familiar, yet unproductive, patterns of behavior.

In a recent post, Joyce explained the importance of context in our work. Her post was about providing context for both your current and future audiences. But what if those audiences can't or won't use the documents? Even if you provide context for your requirements like Joyce suggests, if you don't deliver your requirements to your stakeholders in a way they can or will use (in other words, provide them in the context of their use) then you've completely missed the boat.

Unfortunately, many times we don't find out that stakeholders can't or won't use the documented requirements until it's too late -- the system has been built, it doesn't meet the requirements, but it's too late to change anything and still meet the delivery date. When pushed to explain WHY the system doesn't meet the requirements, the stakeholders explain that they thought something was included in the requirements but it wasn't, or the development team explains that they couldn't understand the requirements so they just built what they thought was right, or the test team explains that they were unfamiliar with the format of the requirements so they tested against the existing system instead. Sound familiar?

It would be great if your stakeholders told you up front that they wouldn't use your documentation. That way, you'd have a chance to talk with them about what kinds of documentation they could or would use. You could discuss all of the options for capturing, documenting and managing requirements, and then you could choose the right set together. You could pick the right tools for the context of their use. If only those darn stakeholders would just be straight with you up front, right?

Let's be honest -- it's our job to know that requirements reviews and use are challenges in software development, and more importantly it's our job to find ways to make the process work. Talk with your stakeholders about past projects and requirements efforts. Find out what their context is for the work you're doing. And then use your expertise to come up with and use new approaches and tools that make this project better than the last for everyone involved.