Cart
[Home] [By Thread] [By Date] [Recent Entries]
> From: Bullard, Claude L (Len) [mailto:clbullar@i...] <snip/> > The next problem is getting someone to pay for > the analysis, the tools, the design work, the > implementataion and documentation, the training, > and the redesigns for oopsies. Quite true. Fixing problems can be costly. Not fixing them can be costly, too. I remember one particular system error that cost a company somewhere in the neighborhood of $2 million. It would have cost the company substantially less than that to abide by the sort of sound practices that could have averted that error. I am not trying to cast things in black and white terms, here, and say that nothing should be done on a system until a complete rigorous model of the enterprise is completed. There are many shades of gray out there. The key thing is when a team works on a project, they should endeavor to understand the larger context, rather than view systems as islands. And when an opportunity arises to get different groups working together to solve a larger issue, they should not hesitate to seize the opportunity; it may not be there for long. > But yes, without a thorough understanding, this > is difficult to achieve. There are also granularity > issues that directly affect process. Sometimes, > big Ol'Hog Memo fields have a lot of different > kinds of data in them. One group (the bean counters) > want very deep granularity whereas the proposal writers > and developers neither want nor need to track at > that level yet are the data sources. Quite true, and there is no magic bullet for that problem. It's difficult to get a team to consider requirements in which they have no stake. > And so it goes. I have seen attempts to use manufacturing > paradigms (part = price) forced on software groups > and fail miserably. The models I've typically worked with in my career have been imperfect approximations. When applied with some common sense, they can be useful nonetheless. When the model becomes dogma, problems result. And when something is "forced" on the developers, they tend to just switch into CYA mode rather than being focused on the success of the project. Methodology has gotten a bad rap in many circles because of so many instances in the real world where a burdensome methodology has been imposed in a bureaucratic fashion, or has become dogma. I agree that such attempts typically fail miserably. I have, however, had the good fortune of being able to participate in a couple of process improvement efforts that were genuine collaborative efforts between individuals at different levels of the organization with sincere interest in seeing the effort succeed. In each of these cases, the efforts originated as grass roots initiatives by developers who were tired of working on failed projects, and who understood very well why those projects failed, but did not get the support or cooperation they needed from execs to succeed. When we managed to get that support and cooperation, and were able to introduce useful methodologies and process improvements, it was a wonderfully gratifying experience. We witnessed great benefits from it -- in spite of the fact that the end result was typically uneven, and usually involved considerable compromises. Enterprise architecture was a factor in these efforts, but just to the extent of providing some guiding principles for our efforts, not to the extent of plopping thick binders on everyone's desk and saying "these are the rules you will follow from now on". I remember one particular process improvement effort that ultimately resulted in a 10-20 page document with the word "Guidelines" in the title. And when we said "guidelines", we meant it. It was an aid to project teams, not bureaucratic constraints. And it was very well received because project teams found it useful, and because they had a say in crafting it to begin with. If a team had sufficient justification for breaking the rules, they broke the rules. And meeting business requirements was sufficient justification if the guidelines got in the way of that. We also had an architecture document that was considerably longer than 10-20 pages, but it was still just guiding principles -- not law. I wish more people had the opportunity to participate in such an experience. This stuff really can be done successfully, and its extremely rewarding and enjoyable to be part of such a success. One very big challenge is overcoming the politics and getting the sincere collaboration needed for success. It can't be simply imposed from above, and it cannot succeed as purely a grassroots effort. Getting over the political and cultural challenges is a huge hurdle, and there are certainly environments where the hurdles are simply insurmountable. I have no magic bullet for dealing with this challenge, but I have had the good fortune of witnessing a couple of rare instances where we were able to overcome this hurdle. I hope I will be able to see more such instances in my career.
|
