Blogging section dedicated to the community website.
When I persisted and suggested that requirements and architecture deliverables should be updated as part of the maintenance process, I had another protest. “All that writing? We don’t have time for that!”
I recently suggested to a team that they could make good use of Macroscope documentation in maintenance. There was instant skepticism. I was politely told that I was being naïve – everybody knows there is almost never any existing documentation and what there is will be out of date and can’t be trusted. And so there is no point in creating any new documentation – nobody would use it.
When I asked what they rely on to help with their maintenance work, I heard:
What we do is complicated. Not because of the multiple layers of technology, but because of the multiple dimensions involved in what we do including people, organization, processes, culture, power structure, etc. There is no simple way to put together a good information system that will visibly contribute to business value. But there are some straightforward things we should do – in collaboration with the business – to improve our success rate.
First time exposure to Macroscope can be a daunting experience, some may not even recover from that trauma and subsequently become opponents to its use within an organization. Additionally, people working in a fast-paced environment are looking for a way to increase their chances of completing a successful project but do not have the time to sit and work their way through the Macroscope labyrinth. So how could we help these unfortunate individuals to become successful?
