I thought I would start the morning writing an entry here as I work to get back into the habit of writing on a daily basis. My work meeting schedule is pretty light today so I'm hoping for a productive day, all in all.
I had a good Sunday - breakfast at Denny's and then stopped to visit with Bob and Kai for a while. They were both doing well. After that I circled home and spent a fairly lazy afternoon doing next to nothing.
Monday was typical work chaos. I didn't really accomplish anything, but I did manage to go to a couple of meetings, listen in on a couple of teleconference and keep the email flood down to a small rush. Monday evening I spent watching the latest episode of "Fear the Walking Dead" and reading articles on Flipboard, then a call with TR, and finally curling up in bed to read "Central Station", a new SciFi novel I've been working my way through.
I got a good night sleep and woke up this morning with a head stuffed from allergies. I am going to try and hammer my way through the email backlog (which is sitting at about 40 or so) and work some on the conversion reports I'm overdue on. The main thing I want to say at the end of the day is that I was able to get my arms firmly around the projects I've got rolling.
We've got a pretty powerful weakness in our approach to work. Basically, at a very high level, a project has certain key steps. Discovery, Requirements, Coding, Systems Test, User Test, Deployment.
Our main customer can not seem to get the requirements portion down and so more often than not we go into coding with our customers still working on figuring out exactly what it is they want to do. Previously our upper management did a bad job of getting requirements locked down. We're still struggling in that area - because of the internal politics of corporations, we just can't get to requirements lock. The new management is doing a better job, but there is still a lot of way to go there.
Showing posts with label Requirements Development. Show all posts
Showing posts with label Requirements Development. Show all posts
Tuesday, May 24, 2016
Tuesday, December 11, 2012
In The Land of Development, Process Is King
Today at work I played a truly Machiavellian game in order to get some forward movement on a portion of the project. We have one portion of the project where three different teams are working on an integration - the Evil Corporation and two vendors. This is a part of the project that ran into schedule delays due to poor planning and feeling were high and hostile by the time I got involved.
In order to make the integration work, it was necessary to get down into the nitty-gritty details and line out each individual data element - however, because of the delay and the fact that all three sides were pointing fingers at each other I could not get them to do the detail work. Each group was playing highly defensively, waiting for the other groups to make a move, so they could dodge any blame.
After several fruitless meetings last week where we struggled to get even the most basic questions answered I spent the weekend reading a massive chain of email trying to figure out how to break through through the logjam. The answer was in the changing tone of the emails. As they progressed through time I could see the tone changing to more accusatory, more defensive, less productive, until the reached the point where I had been brought in, which was the point of near total meltdown. Everyone was waiting for someone else to go first, so that if something went wrong they could point a finger at someone else.
So, I over-reached my authority and went first - I wrote up a set of requirements and announced - this is what we are going to do, this is the condition the data is going to be in, this is the place we are going to send the data. You all need to be ready to pick it up when it gets there. Then, I spelled out, in some detail, what I was planning to do.
Of course, it was wrong, largely because I was making it up out of whole cloth - but one of the vendor rose to the bait and said "that's not right", which opened up the door for me to simply say "tell me exactly where it is wrong, and what change needs to be made to make it right". They tried to dance, but I just drew back to my original proposal and said "absent detailed input, I am making a best guess and doing it this way, and I have no problem documenting it as a best guess in the lieu of more detailed information" - and that was enough to prompt, first, the two vendors to talk to each other, then the whole team to get talking. When I left tonight, I have two thirds buy in and one third outstanding.
It was pretty Machiavellian, but it was the only thing I could think of to break through the positions that everyone had hunkered down in. Sometimes a stalking horse serves a good as well as a real horse. Of course, none of this would have been necessary if we'd actually followed any sort of good engineering process from the beginning. What appears to have bitten them on this end of the project was that no one wanted to do the grunt work - and everyone preferred to assume that someone else was doing it, so there were no detailed documented system requirements.
When it comes to software development, process is king.
In order to make the integration work, it was necessary to get down into the nitty-gritty details and line out each individual data element - however, because of the delay and the fact that all three sides were pointing fingers at each other I could not get them to do the detail work. Each group was playing highly defensively, waiting for the other groups to make a move, so they could dodge any blame.
After several fruitless meetings last week where we struggled to get even the most basic questions answered I spent the weekend reading a massive chain of email trying to figure out how to break through through the logjam. The answer was in the changing tone of the emails. As they progressed through time I could see the tone changing to more accusatory, more defensive, less productive, until the reached the point where I had been brought in, which was the point of near total meltdown. Everyone was waiting for someone else to go first, so that if something went wrong they could point a finger at someone else.
So, I over-reached my authority and went first - I wrote up a set of requirements and announced - this is what we are going to do, this is the condition the data is going to be in, this is the place we are going to send the data. You all need to be ready to pick it up when it gets there. Then, I spelled out, in some detail, what I was planning to do.
Of course, it was wrong, largely because I was making it up out of whole cloth - but one of the vendor rose to the bait and said "that's not right", which opened up the door for me to simply say "tell me exactly where it is wrong, and what change needs to be made to make it right". They tried to dance, but I just drew back to my original proposal and said "absent detailed input, I am making a best guess and doing it this way, and I have no problem documenting it as a best guess in the lieu of more detailed information" - and that was enough to prompt, first, the two vendors to talk to each other, then the whole team to get talking. When I left tonight, I have two thirds buy in and one third outstanding.
It was pretty Machiavellian, but it was the only thing I could think of to break through the positions that everyone had hunkered down in. Sometimes a stalking horse serves a good as well as a real horse. Of course, none of this would have been necessary if we'd actually followed any sort of good engineering process from the beginning. What appears to have bitten them on this end of the project was that no one wanted to do the grunt work - and everyone preferred to assume that someone else was doing it, so there were no detailed documented system requirements.
When it comes to software development, process is king.
Subscribe to:
Posts (Atom)