<body><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener('load', function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <div id="navbar-iframe-container"></div> <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script> <script type="text/javascript"> gapi.load("gapi.iframes:gapi.iframes.style.bubble", function() { if (gapi.iframes && gapi.iframes.getContext) { gapi.iframes.getContext().openChild({ url: 'https://www.blogger.com/navbar.g?targetBlogID\x3d7181760\x26blogName\x3dOffpoint+-+From+Singapore+To+Seattle\x26publishMode\x3dPUBLISH_MODE_BLOGSPOT\x26navbarType\x3dBLUE\x26layoutType\x3dCLASSIC\x26searchRoot\x3dhttp://offpoint.blogspot.com/search\x26blogLocale\x3den_US\x26v\x3d2\x26homepageUrl\x3dhttp://offpoint.blogspot.com/\x26vt\x3d-740194547652384018', where: document.getElementById("navbar-iframe-container"), id: "navbar-iframe" }); } }); </script>
Wednesday, May 21, 2008
Dare I say something?

Glad to see that Dare's back to blogging regularly again. Even though his blog doesn't cover anything specifically on antimalware or security, his direct tone has been very enjoyable by me.

One of his first posts after his hiatus really highlight the key issues that I've seen as a challenge to my service's quality.

Fundamentally, the development and project management model that were placed on my service had a number of flawed assumptions, which resulted in the series of constant issues.

Firstly, as Dare has mentioned as well, was the fact that there is (and was) a misalignment of goals from the various teams. Regardless of whether the various sub-teams were reporting to the same executive or not, it doesn't remove the fact that my team and myself is focused on one single goal: quality of service in terms of antimalware scanning coverage.

Some teams that utilize the service have other goals; one specifically to do with processing time. We want higher level of coverage; they want increasingly shorter processing time. Now isn't this a major disparity right here?

What are the chances that we can get the features and coverage that we need?

Since most of the upgrades were treated as projects, one can't miss the fact that project members have project goals that implicitly meant if a project complete, they met their goals. Nothing to do with what the service is actually capable of sustaining or improving its coverage or not.

When the majority of the project members want to focus on just completing the project, a single voice of sanity meant one will be treated as someone that is not willing to collaborate, and might be slighted or even disassociated from the project or the service as a result.

Dare's second point was about the undisclosed concerns (read his post for more details!). Indeed, risk mitigation isn't something that any project members would want to bring up as an work effort to look into. This becomes even more of a problem when one team continuously is unable to provide results of quality; or completed on time.

What can be done about this? I always wonder about it. And then something lit in Amsterdam and it hit me... (i'm sure there wasn't any weed influence at all in Amsterdam).

Acknowledge: that something needs to be done, because status quo is not going to be good for any teams or any service. By putting your head in the sand and think that the issues will go away is the worst possible thing one can do. As something perhaps Dr. Phil might say, acknowledge that the model is flawed is the first step.

Listen: Spend time to listen to the folks that really want a quality service. No more brown-noses to cloud your thinking. If you do not want to listen, no one will tell you anything that needs to be worked on anymore.

Talk: Get the team members worked up with a plan and a roadmap. Every single step towards a better future will energize the teams and create a common goal for everyone. That increases the morale and refocuses everyone's efforts. Talk about your strategies, and your limitations. We can work better if we know what your constraints are. Without that, we will assume that there's some other agenda clouding your decision.

Act: Quickly. Any faults along the way must be fixed with immediate speed. Again, the same old soft-landing approach for folks is no longer working. No more soft landing for anyone. Streamline the cohort of distractions that are creating churn for everyone. Redefine communication channels with the goal of speed of communications. Make it specific and clear cut that issues need to be looked at by the ones that matter, rather than a committee or a bunch of committee that manage-by-agreement. That's almost like trying to get an elephant that was described by three blind men. You can't.

Hmm.. i wonder what else...

posted by Jonathan at 12:21 AM | Permalink |