That got my attention.

I’m a raging introvert so when I won’t shut up, it’s usually about something I’m really passionate about or something I think I know a lot about. One of the objectives I set for myself at PSL was to learn how to be a better listener. I felt I accomplished that, or at least made substantial progress, and rewarded myself with the muzzle award for knowing when to shut up.

I don’t want this post too be too long so I’ll skip the examples where I channelled the image of Johanna pounding her hand on the table to keep me in line. Needless to say, I was more aware of my disposition and sense of knowing when to shut up than I was before.

Over the last few weeks after coming back from Agile 2011, I felt like I ‘gave up‘ a little.  In retrospect, I started to slip back into old habits of telling and not listening which wasn’t really helping me or the people in my life.  

My boss had reflected this back to me during a recent one-on-one so I’ve had some time to digest the feedback. More specifically, I thought about our one-on-one conversation and how much of it was us talking ‘at‘ each other instead of communicating.  We started well and I gave up my new listening skills early on which I think was the cause. Having said that, it was a productive chat, I feel it could have been better if I had channelled Johanna’s table-pounding image in my head.

I started looking deeper and another lesson from PSL started becoming clear. If you want to change anything, start with yourself.  I started thinking about bad conversations (work and home) and what problems I was facing and what of my behavior or lack of listening was contributing to those problems.

Today I set out to take those lessons and apply them. During my first meeting I caught myself interrupting someone 3 times. I caught myself early which I was proud of. I also used what I learned from Declan and Bryan’s ‘Pull conversation’ session at Agile 2011 to have better conversations with the people in the meeting.  I hope it helped, I felt better. I suppose I could ask them tomorrow.

Here’s how I would sum up what I learned with what I tried today (and what I like to preach to others about!)

• It’s not about them, it’s about you. Once you understand yourself better, you will be able to interact with people better. I found MBTI very helpful in this regard.
• Change starts with you first. You can’t, nor should you try, to control or influence people. I am using ‘influence‘ in the negative sense of ‘tricking‘ people, not ‘influencing‘ in the sense of persuading people that your idea is the best.
• People are good and are doing the best they can with what they have, whether that be skills or external forces (ie: is a co-worker who you think is an asshole just somebody who’s a really passionate person or maybe they’re going through a divorce. You don’t know whats going on in their head)
• Listen to people by reflecting back what they are saying. Use questions like “I’m not sure what you mean, can you describe an example?” or “I interpret that as ABC, is that what you mean or did I miss the point?“. There are many ways to ask “pull” questions but the point is that you may process information differently than the person who is transmitting, try and understand where they are coming from so your ideas and thoughts can converge.
• I find this helpful, prepare for conversations ahead of time, especially if you are introverted. I need time to process information so my emotional response comes out first if Johanna doesn’t pound the table quick enough.
• Find a technique that will help you stay focused, like my example of Johanna pounding the table.
• Stop a conversation at the sign of trouble. I am still learning how to do this because dammit, I’m right and I have to prove to you that I am right! This is probably the weakest area of conversation skill for me.

Before this meeting I made a conscious effort to be aware of my state and how I was engaging in the conversation.  I also set some mental pointers about specific things I wanted to improve on.  One of them was not interrupting.  The other was staying engaged by making a note of my physical posture.  When I felt like I was dis-engaging, my body language gave me queues and I corrected it.  I’m sure this probably sounds nuts, but I ended up thinking “posture matters, sit up…” in my mind.

I’ve been struggling with a closing paragraph for a good 15 – 20 minutes.  If I could share one last thing from this post it would be that you are responsible for your personal development.  If you’re unhappy with the status quo, remember, It doesn’t need to be this way.  Change yourself first, you’ll thank yourself when you realize how good it feels.

One Monday I walked over to her desk to see how things were going because I had heard there was a pretty severe production problem over the weekend.  That was a pretty common occurance and since Joyce had been there so long, she was always getting pulled into these problems.   She had just finished a conversation with her boss.

I could see her standing up behind her desk chair as I walked closer and could see she was using the chair to support herself.  I asked her what was the matter and she said her back was a bit sore, I knew there was something more to it.

I suggested it would be a good idea for her to go home, she didn’t look good and odds are somebody else can figure out what was happening with the production problem.  She said she “had to stay” and wouldn’t be able to rest at home anyway so she was going to stay.

I had later found out she had a bad reaction to some medication as a result of a back problem which was making her situation worse.  I tried to convince her again to go home and offered to talk to her boss but she said she had told her boss she’s ok to stay long enough to help with this fix.

At that point I started getting really upset…especially at her boss.  How could anyone consider any work related problem to be more important than their own health and the health of their co-workers.

I wrote down 3 words on a piece of paper and gave it to her:

Health
Family

Work.

I told her she always has a choice and health comes first.  Without health you cannot take care of your family.  That’s what matters and again I tried to persuade her to go home and that I’d talk to her boss, but she persisted, and I let it go.

By this point I was absolutely furious at her boss, regardless if it was her boss that was pressuring her or not.  Granted Joyce is partially responsible in the decision to stay, but I was fuming nonetheless.

Since I was a consultant I decided to go home myself because I was in no mood to be in that environment at the time.  I canceled all my meetings, went home and didn’t bill for the half-day I was there.

I’m sure Joyce’s case is an extreme one, but I have seen time and time again where people value work as being more important than their own health.  I’ve known many so called work-a-holics or heros that like to joke about “well, I’m going to be here ’till midnight anyway! ha ha ha…”  and I will admit, I used to be one.   Joyce helped me understand….really understand… what’s important.

From that moment on I have been very attentive of work/life balance.  Sure there’s the occasional long night, but it’s rare.  When I leave the office at the end of the day, I leave the office physically and mentally.

Agile talks about ‘sustainable pace‘ and it wasn’t until that experience with Joyce that I really got it.  I wrote this post as a response to a tweet from Ron Karr:

“How likely are you to drop everything at work to attend to family matters?http://bit.ly/mBSCRP“

I didn’t read the article he referenced in his tweet, only the tweet itself  and replied with:

“@ronkarr for me, very likely. Priorities are Health, family and work. In that order.”

I’ve found people can be pulled so far into the status quo that daily drama can be like a drug.  It’s often easier to respond to drama than to do something differently.  Remember this, as Jerry Weinberg told us at PSL, it doesn’t need to be this way.

I remember working with a team in a company that had agreed to do their morning standup at 9.30am.  Quickly afterwards a pattern had developed where a couple of team members would be a few minutes late, then they would arrive later and later to the point where some team members would start criticizing the late team members.  ”Why can’t he just be on time?  We said we would have the standup at 9.30, what’s wrong with him?“

There could be a number of factors contributing to why these couple of team members were late, so what can you, as a manager, do about this?

People are doing the best they can with what they have.  Life is complex, people have families, doctor’s appointments and other commitments outside of work.  In the case of the late team members, a better approach than forcing them to “be on time” is to understand the reasons behind the lateness.  Do they go to the gym in the morning?  Do they drop their kids off at daycare? In my case, I’m an introvert so I need a lot of sleep and getting up early can be really hard for me sometimes.  I’ll do my best to get into work early sometimes but my pattern is that I show up anywhere between 8am and 9.30am.

Usually what I’ve experienced is things like “how can we enforce people coming in on time?”  ”how can we punish these people for being late?”

I will admit I have done this and am kicking myself for doing it.   Many years ago when I was younger and more stupid, I instituted a policy around being late for the standup.  I said anyone who is late must pay a fine because the team was annoyed that some people were constantly late.  The first day I was purposely late and paid the fine to show I wasn’t exempt from the policy.  What a dumb idea.  Seriously, what a dumb idea, but I didn’t know any better at the time.

So the lesson is, understand the reasons behind why an employee is behaving a certain way and work with them to help them improve on it instead of punishing or trying to force a certain behaviour.    People are different and respond to feedback differently.  I respond well to direct feedback, no matter how brutal.  I don’t always like it, but I prefer it.  Some people may respond negatively to that type of feedback.  Understand your co-workers and understand people aren’t malicious.  Think of it this way, do you go to work with the intent of doing something harmful or pissing off your co-workers?

Ok, that’s one problem addressed, what about the reaction of managers?  That’s a problem too.  Managers who punish employees with the stick do so because that’s what they know.  They too are behaving like that for numerous reasons.  They could have had a bad manager in the past, they might not even want to be a manager and don’t know how to become one.  I remember being given my first “Director” title when I was 29.  How stupid is that?  I had one year of management experience at the time.  It sounded cool and it looks good on my resume but I was in no way ready for the responsibility of that job.  I didn’t know any better at the time but I did have a fantastic manager who helped me understand what being a good manager was.

My actions throughout that role were the best I could do with what I had at the time.  That included experience and training.  I did a lot of stupid things back then and was a real pain in the ass to work with.  I didn’t know what else to do.  From my experience most people become managers because they are the ‘expert’ in their field.  Then these managers end up doing most of the work instead of managing the team.  I’ve been there too.

So as a manager, what can you do?  You’re not a bad person, you’re doing the best you can with what you have.  If you don’t know how to be a great manager, get training.  Read books.  Go to conferences and talk to other managers.  Tell your boss you don’t want to be a manager yet.  There’s no shortage of what you can do to improve yourself.  Remember, there are systemic forces on you too.  If you are getting pressure from your boss to deliver results, that pressure will get pushed onto the team.

Remember, people are doing the best they can with what they have, as a manager you have a responsibility to understand the people you manage and you have a responsibility to develop your management skills.  No one else, including your company, are responsible for your skills.  It’s great if your company will help but at the end of the day greatness comes from inside you and you have much more control over that than you may think.

Original Post:

A couple of years ago I was talking to Don Gray about “seeing the train wreck” in advance of it happening.  By this, I mean it can be hard for managers to take an objective look at what’s really going on in their organization.  We were talking about observations we made while at client sites that seem to be completely oblivious to the people working there.

Why is that?

Are organizations blind? Am I imagining things?

One of the skills I’ve been refining over the last couple of years is observing systems and the people in them.  Sometimes as a coach/consultant your job is to just watch what’s happening and help the organization “see” by helping them look in the mirror.  Often people within organizations don’t have the same perspective as an outside coach or consultant.  I remember walking into a client office one time and “feeling” the stress in the air.  Before I talked to anyone, I went right into the VP’s office and said “what happened today?  People seem really stressed out.”

He was quite surprised to hear that, there had been a large production emergency that create a rather nasty ripple throughout the company.  For me it was no big deal, I wasn’t part of the system, I was a consultant and it was easier for me to see that stuff.

That was as much as I had written at the time.  Fast-forward to the present with 80% new and improved insights!

One time I was working with a team and was observing their retrospective.  Their manager (who is also a team member)  had been away for most of the sprint and the team mentioned in the ‘what went well’ list that they had got all the work in the sprint done.  They also mentioned in their ‘not well’ list that it was hard to make decisions without their manager being there.  But they did make those decisions.  And they got all the work done, imagine that.    One of the team members who was handling adhoc requests had mentioned that it would have been nice to be part of the core team and working on the same work as everybody else.  He felt it was almost possible this time, but then again, maybe it’ll somehow work out next time (without actually changing anything).

That team member had been with the team for about 3 or 4 sprints if I remember correctly.  History was showing many adhoc requests and not once had he been involved with the regular team work to this point.

I remember sitting there thinking “wow, can’t they see that?  What’s wrong with them?  Do they really think things are just going to magically get better by doing nothing?  There’s no ‘what to try’ for the next sprint, no discussions, nothing! They think it’s ok to have to wait for their manager to decide on everything? They call themselves and agile team?  Sheesh…”

Then I realized something and I will have to thank PSL for that.  It’s not them.  It’s me.  The team was happy.  They were happy to get all the work done without their manager and they were also happy they didn’t have to go through the pain of having to make their own decisions without their manager now that he was back.

There is nothing wrong with that.  The work got done, the team was happy.   I wouldn’t call them an ‘Agile’ team, but what they are doing works well enough for their culture and there’s really no need to do anything differently.

In an organization that relies on control and hierarchy, having a self-organizing team might not be the right thing to do and it can cause more damage to the system by disrupting the culture if the team starts to make their own decisions that management doesn’t agree with.

What I learned at PSL helped me realize that my observations were more about me than anything else.  If you are familiar with Myers Briggs, my type is ISTP (Introverted, Sensing, Thinking, Perceiving). One trait of an ISTP is keen observation skills because of our dominant Introverted Thinking preference coupled with our auxiliary Extroverted Sensing preference.  If that doesn’t mean anything to you, here’s the simple version:

ISTP’s gather data from the outside world through our five senses and then internalize it quickly.  It’s sorta like in The Empire Strikes Back when Luke ‘feels’ that his friends are in pain on Bespin.  Cool eh?   ISTP’s are great in a crisis and sometimes invent problems so we can solve them.    It may actually be a real problem, it may not be but to me, my observation is my observation so I am learning how to be more aware of the system the problem is in so I can make better decisions.

I’m rambling.

The important lesson I learned is to figure out a more gentle approach to holding a mirror up in front of a team or organization because I may simply be over-analyzing a situation or making an observation into a problem that doesn’t exist.   Either that or the organization is just in denial!  There are many reasons why organizations and teams behave the way they do and I’ve worked with many teams, some that just ‘get it‘ and some that don’t and that’s fine.   At the end of day what matters is that the organization is happy with the results whether it be from a team that is led by their manager or an Agile team that really gets Kaizen.

If your organization is struggling with Agile, there’s a reason for it.  The practices your attempting may clash with your culture.  You may be trying a certain practice that conflicts with the type of work you are doing (IE: trying to use Scrum for support or software maintenance)  You may have managers with personality traits that conflict with ‘embracing uncertainty‘ so they aren’t able to transform from a control oriented manager to an Agile manager.    It could be any number of things, once you figure out your culture, organizational goals and understand your people and the work they do, you’ll be in a better position to see if you really need to adopt Agile in the first place.  And you’ll have a better idea of how to go about doing it.

“I have learned to think in my own context”  Of course he admitted that the marketing of that term isn’t so great when you’re a consultant, however, the heart of that statement is what really matters over trying to put a label on what process discipline you’re using.

What I’ve seemed to notice more is that people inside the “community” (whether that be agile, lean, scrum or whatever) spend a great deal of time trying to refine their brands and labels and I am wondering if people outside these communities really care about (or even understand) the brand or label.  We in the community make assumptions about how our customers feel about our brand and worry about language, marketing and other stuff that sounds an aweful lot like making product decisions from an ivory tower without getting fast feedback from our customers to me.

Let me  explain that a bit more.

Organizations may look to “Agile” to help them with a problem.  They might not understand the problem, but they know enough to know that they want or need something to change.  So people in the organization will talk to colleagues or friends or other industry people they know.  These people they talk to may say things like “hey, we started Agile-ing a couple of years ago and wow, the magic I tells ya! We started Scrumming our products and holy cow is it awesome!”  Ok, maybe that was not exactly how the conversation would go, but I think you get the idea.  The organization looking for help sees that a certain process worked in another company from a trusted source of information so naturally, it’ll work for them.

So this organization will start doing Scrum.  Then they’ll realize it didn’t work, or at least it didn’t get them the outcomes they thought it would.  Then they’ll wonder if they’re doing Scrum right.  Then they’ll find out they are doing Scrum-but.  Then they’ll be confused.  All the while the focus has shifted from trying to figure out why they needed to change something and the focus will be put on how to execute the process (in this case Scrum) the right way so it’ll work.

They may try Kanban and see how that goes or they may try Lean or Crystal or <insert process here> or they may chose to just give up and go back to the status quo or do nothing.

I am going to tell you the only guaranteed, sure-fire way to get better results within your business.

1. Start trolling the Yahoo or Google message boards of various process disciplines.  Linked In is a good place to start too. Post thoughts about your problems and get some free advice.
2. Filter that information and decide on which process discipline makes the most sense to start with
3. Get involved in that process discipline’s community.  That means find local user groups, go to conferences and spend some time and effort to make a well-informed choice.  Of course balance how long it takes to make the choice.  Chances are you’ll get analysis paralysis if you spend too much time.
4. Hire a consultant (and I’m not one anymore so I’m not plugging myself!)
5. Give’er!  Get started while understanding that the focus is NOT on the process but instead the outcomes you expect to get.  Use what you learned in the first 3 steps to teach yourself and your organization how to learn within your context.

While I did use numbering for these steps, they’re not really linear.  My point is, educate yourself through the massive amounts of information and channels before you decide to make a change.  Understand what problems you think you’re trying to solve, understand there’s probably more problems than you originally imagined and gather information and feedback from various sources to help you make a more informed decision.

So for the amount of time and effort people within the community spend on defining brands and putting labels on processes, are our customers finding any value in that or are we just confusing them with a bunch of BS that doesn’t matter to them?  Are we the reason that focus seems to shift from solving business problems to following a process?

Seems simple to me, the organizations and people who are content with mediocrity will pursue quick fixes and focus on doing a <insert process discipline here> right.

The organizations and people that want to improve will actively seek out solutions and labels won’t matter to them.  They ‘ll look at multiple process disciplines and they’ll get actively involved in one or many communities and they’ll learn how to think in their own context for how best to apply the right practice(s).

“Learn how to think in your own context” – It doesn’t get much simpler than that.

Well, one key has a really big-ass keychain and people would put 2 keys on one push-pin and more often than not while putting the key back or taking it off, they other key on the same pushpin would fall off.  Being the nerd I am, I watched this behaviour for a few days.  Sometimes a key would fall on the floor, sometimes not however status quo was very much apparent.  It’s just a key after all, no big deal just bending down to pick it up if it falls.

I decided to introduce a system change.  I added another push-pin.  3 keys, 3 hooks.  A funny thing happened.  Most people still put 2 keys on one hook and didn’t use the new hook that is pretty obvious to spot.  I decided to experiment further.  I’d always put the 3rd key on the 3rd hook and check and see how often the keys ended up being doubled-up on one hook.  Most people still doubled-up keys.

What’s the point of this nonsense?  People are generally happy with the status quo.   As I’m typing this, someone came back and doubled-up the keys.  He fumbled with it, but it didn’t fall on the floor.  Going back to the premise of why Agile is so hard, if this simple of a system change doesn’t change behaviour, can you really expect your organization is going to leap at the opportunity and embrace the disruption to the status quo?

This leads me to another test.  What’ll happen if I remove 2 hooks leaving only 1?  What happens if I remove all hooks and leave the keys on the floor?  Perhaps my sensitivity is getting the best of me, however it’s little cues and behaviour that can speak volumes about your organizations culture.  What’s going to happen when you introduce a new process that makes employees feel less safe?  What’s going to happen when Agile processes expose problems in your organization?  What’s going to happen when you attempt to adopt a particular Agile practice that requires more complex behaviour change?

That reminded me of a recent sprint planning session our team had.  Our product owner considered customer value and done as being able to clearly show separation of presentation and data layers in a new service we’re developing.  I considered customer value being showing the user of the new service a simple interpretation of the data being shown through the service.  Very different perspectives.

For me ‘done’ is when the customer gets something valuable.  For our PO, ‘done’ is when he can be satisfied with the design of the service.  The team, done is when all the yellow stickies are moved to ‘done’.

The point is, my tax example is simple and very specific.  Just before I wrote this post I told my wife I finished both returns, filed mine since I get a refund and will file her’s at the deadline since she has to pay this year (booooooo!….for her!).  Before that, I have no idea what she thought ‘done’ was.

Software is much more complex than that.  One way of handling this is to periodically align the team during the sprint.  Oddly enough I did that yesterday.  Our standup felt kinda ‘status-y’ and there really wasn’t much talk about the actual work.  I pushed the team and asked them to say what they thought we agreed to delivering.  I asked the PO the same thing.

I was pleased to hear it was the same as what I thought so I wrote it down and stuck it on our release wall.  Might be tough to see in the picture, the green card on the left shows the sprint number and what our definition of ‘done’ is from the customer’s perspective since that’s what our sales and marketing team would find valuable.  They could care less if the service is de-coupled.

When you talk about ‘done’, be specific.  Scrum talks about delivering ‘business value’ and ‘potentially shippable’ software which is just a guideline.  Be specific and you’ll avoid a whole whack of ugle “hey, that’s not what I thought we were gunna get!” conversations later.

Michael Sahota taught me this trick, stop using the word “should” and I found that the message stuck.  ”Should” is the easiest way to removing all sense of responsibility for your actions or team conclusions.  When I hear a team member say “we should do X”, often the rest of the team nods and nothing gets done.  I just caught myself doing this.

A team member sent around a list of great testing webinars that are coming up and I started to reply via email: “That’s awesome, we should sign up for the xxxx…..”

I stopped myself before sending.

I decided to register for it and changed my reply to “I will sign us up for session xxx and I will be in the open space area with the projector for anyone who is able to join.”

Amazing how something so simple can be so effective.    ”Should” is often used with the best intentions, however that word doesn’t lend itself to creating actionable output.  Change “Should” to “I will” or if you’re not able to take action, change “Should” to  ”Can you…” and ask for help.

Each month I’m picking the top 3 -5 new things I’ve learned and tried in the hopes it will help me keep my commitment to improving and to share what I’ve learned with others.

1) Knowing when to shut up: I learned this in Michael Spayd’s coaching circle.  We were practicing powerful questions and Bill, one of the participants, asked a really powerful question then proceeded to explain the question.  Michael jumped in and reflected back to us how the power of the question was lost after the explanation.  Michael and Lyssa Adkins have been delivering Agile Coaching training and a statement he mentioned was “As a coach, your job is to shut up!”.

I tried this recently after a coding kata with the team I’m on.  Usually I jump in and clarify and give my opinion in an attempt to tell people what I think they should have learned.  This time I just shut my mouth and it ‘felt’ better to have the team realize and learn something even if I didn’t agree with what they learned.

2) Asking permission for my opinion:  This was another lesson from my coaching circle.  During a real-life scenario practice session each person had the opportunity to provide insight to Alisson, who brought the scenario.  When it came time for Michael to provide insight, he asked Alison: “Can I give you my opinion?”  Simple, yet effective.   I’ve been on the side of getting opinions dumped on me, it’s not fun.  Asking this question helps prepare the person for what is coming.

I tried this a few times since then.   As an internal coach, my approach is less directive than it would be as an external coach.  I find asking for permission creates a sense of personal safety for the person I’m giving advice to.

3) Remembering peoples names: I really suck at this.  I blame my introverted-ness.  I was in a meeting with 7 or 8 people at a client’s office.  On my notepad, I drew a diagram of the table and wrote down the names of the people as we went around the table with introductions.  When each person spoke in the meeting I checked the diagram to put a voice and face to the name.  After the meeting I thanked each person, using their name in my comment.  That really helped.  I can still visualize each person’s face and where they were sitting so the next time I had a meeting there, I remembered their names.

As with all things, it takes practice to improve.  Having a new level of awareness about these new things I’ve learned, give me the opportunity to practice and improve myself.   How do you keep up a commitment to learning?  Would love to hear your feedback!

I’m working on a distributed project involving 3 companies, one of which is the solution partner who has a more rigid process than we do.   Perhaps that’s a bit un-fair, it’s more of a case of “big doc upfront for sign-off” and then an iterative process for the delivery phase.  BRD’s, sign-offs, complex change management and internal process control are not things my company worries about, however our solution partner does.

Odds are we’re not likely to change how an enterprise company operates with this 1 project and have to figure out where to compromise.   From experience, big documents, deliverables and timelines are generally bullshit.   They take the focus away from building software and put the focus on politics and artifacts which can have a whole other level of un-intended consequences attached to them.

I won’t go into those gory details here, that’s not the point of this post.

The point is, your Agile isn’t my Agile, and any project that requires a “big ridiculous document” (BRD, thanks to Gil Broza for that!) I wouldn’t consider to be an Agile project however in some cases, is it what it is and I can try to convince everyone involved why big ridiculous documents don’t make much sense or figure out the best compromise to keep the focus on the project itself and not the process of how the project runs.

When I decide where to push and where not to push, context really matters.  In the case of this project, these are some of the factors for figuring out where to compromise my principles:

• this project took about 4 years to come to realization
• this project is in an extremely conservative industry
• this project has conservative stakeholders
• there are contracts, budgets and other real-life stuff that MATTERS to these stakeholders who are PAYING for it
• the company building the solution have their own internal processes that are more rigid than ours

I remember a conversation I had with a couple of middle-to-high managers/directors at a larger company once and they were pressuring me to commit to a fixed scope, fixed date project  with a brand new team, most of which had no prior knowledge of the system.  After I finished telling them how wrong and stupid they were (nicely, of course) the project was no worse or better off and ultimately my failure to understand their perspective didn’t give me any opportunity to get future help from them or be thought of as anything but one of those crazy Agile know-it-alls.

It was a great lesson to learn.  So this time, I have a much better understanding of how to be aware of what is important to the people who are involved in the project and I know areas where I need to compromise and areas where I can influence more.

It’s by no means ideal, especially considering this is now week 5 of the project and we haven’t got into the real meat of building it (it’s a bought solution with customizations so there IS some form of ‘working software’ already) but it’s the best we can do given the contraints we have at the moment.  I fully expect that all to change when we start building…