One of the interesting parts of starting a new OSS project or new customer is figuring out their mode of operation. For example, some architects want high-level requirements to design their own solution against. Others want you to document the requirements so tightly that you’re effectively designing the solution for them (eg field mappings, data structures, interface designs, etc).
I’m comfortable operating in either mode (and have done so), although being a designer / engineer at heart, I can sometimes err on the side of getting into solution mode. In general, I figure there’s little point in trying to change those with a fear of change and am happy to go into whichever mode it takes to get progress. I find this especially true in the large, bureaucratic organisations where OSS are often implemented.
Many others disagree with this approach and prefer to enforce their own mode of working onto their new colleagues. I’ve only ever found that this leads to delays – direct and indirect.
What do you think?
Earlier this week, I was lucky enough to be introduced to a talented RAN automation expert. He’s one of Australia’s foremost, hands-on, experts on SON
I was listening to a group of telco experts on a podcast the other day. As they were talking, I kept picturing the image of
Earlier in the year, we wrote a series of articles about the chasm that exists between OSS/BSS buyers and sellers (pt1, pt2, pt3, pt4, pt5, pt6). “The chasm” is
Actually, maybe a few related questions. As you’ve seen from recent articles such as this, I’m increasingly interested in the cross-over worlds of comms and
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
