As much as I like SharePoint, I still think it has opportunities to get even better with its usability and the intuitiveness built in the user interface. By this I mean the modern day SharePoint will continue to improve. But the project I’m referring to was a couple versions ago, way back on SharePoint 2003. I’ve found the product has come a long way since then and really appreciate the improvements the team has made.

But I was under no delusions back then about the challenges in the user experience and interface. I knew it was a struggle for anyone to get comfortable with it, and users needed all the training resources and support they could get. One of my friends summed up a user’s experience with SharePoint nicely for me back then when he suggested I write a book titled “Clicking Your Way out of SharePoint Circles.” To him back then, the interface just seemed to have confusing links and menus that left you feeling like you were going in circles. (Unfortunately, I think I missed my window writing that book, because SharePoint doesn’t seem to send you in quite as many circles anymore).

Ultimately we had to address user training. I created a couple of half-day workshops and delivered several to users, offering them some hands-on experience walking through some key scenarios that would get them going with SharePoint. With the workshop I printed out a workbook I created to give each attendee so they would also have a handy reference of a handful of tasks that we figured would be the most popular for the users. I also created some quick reference sheets that listed key tasks to help get people productive quickly.

One thing I noticed was that in the locations where we didn’t offer much training also ended up being the locations with the lowest adoption rates and the highest support calls. The locations with the most training had the most enthusiastic adoption. Creating the training materials and scheduling workshops was an eleventh hour response when it was painfully obvious to everyone that end-users needed training, but getting readiness resources in place made all the difference for a successful rollout.

I remember one of the consultants from another company was capturing some governance decisions in a document. This seemed to include things like the URLs, the site structure, and other technical details like this. None addressed any organizational impact issues, like one of the most critical: end-user training. But they felt pretty good with themselves, because they documented things like the list of URLs and some verbiage on site collections and called that a governance plan.

Fast forward to today, and although the SharePoint product team has greatly improved the user experience, users still need training and readiness resources. This is true no matter how sophisticated or technical you feel your users are. I’ve always found the best time to plan end-user training is early on in the deployment process, leaving ample time to get all the necessary readiness resources in place in time for when the users need it most.

More importantly than pushing information, he wanted anyone within the organization to be able to comment on his posts, to the point that people could event submit comments anonymously. He wanted a channel he could use to feel the organization’s pulse directly, to capture feedback uncensored from anyone in his organization who is willing to share their thoughts.

We weren’t working specifically on governance, but here was a major governance decision made with the weight of an executive sponsor. From the top, we were told that communication was to flow freely; the team was not going to walk on egg shells or try to keep things safe. We were told not to be scared of what someone might post, that the point was to let people post candidly what was one their minds.

This decision is pretty significant, because this is a company that would normally be considered fairly conservative: it was a telecommunications company after all. Can you imagine? Deciding to create a channel where anyone within the company could post whatever is on their mind, positive or negative, as a comment in response to one of the president’s blog posts, and even submit their comment anonymously. And all the comments are posted in real time – no workflows for approvals, they’re posted right away and available for all to see.

I must confess we didn’t trust users 100%, even though our mandate was to allow free and open communication. Our thinking was that sometimes people could get emotional and type very inappropriate text that could offend others. So even though we created new a communication channel, we also wanted to be sensitive of the fact that some words might be too offensive to expose to the company through someone’s comment posted in the heat of the moment. But we didn’t want to throw the baby out with the bath water at the same time by adding extra overhead like an approval process to the comments, since our mandate was realtime and open communication.

The way we solved this concern was to develop a bad word filter. Rather than involve a moderator, we generated a list of words or phrases that most likely would be interrupted as offensive without filtering out legitimate words that sometimes could be used in a slanderous manner. Our filter would parse the comment text whenever a user submitted their comment, and perform a match against those bad words, replacing them with asterisk characters instead.

This customer wasn’t explicitly conducting a governance exercise, but made powerful governance decisions related to social computing policies within their organization. The team implemented the solution within a couple of weeks with the bad word filtering in place, in a sense governing the users comments by allowing them to freely enter whatever is on their mind while the system takes care of filtering out only the most offensive words.

On a side note: I don’t think I’ve ever had a project team enjoy the testing phase of a project as much as this team did. No question, I was impressed with how enthusiastic and passionate every member of the team was about testing as we were putting the bad word filter I developed through a rigorous testing process.

A couple years ago I had an engagement with a utility company that supplies power for a region. They store a lot of content concerning a wide variety of topics, and with a complex structure of privacy and compliance needs. This company’s content security needs ranged from information pamphlets that encouraged people to save power and were available for all to see, across to the other end of the spectrum that includes architecture diagrams of power plants that have to be protected and secured.

For example, the company’s diagrams had an inherent threat attached to them, for if they fell into the wrong hands they could be used for something like a terrorist attack since they may expose vulnerabilities about a power generation facility and the optimum place to attack it. The company’s power stations potentially could be considered as high-value targets for terrorists if they wanted to interrupt the availability of power for a power grid.

Beyond threats of information security breaches leading from potential attacks, the company also has privacy concerns with some of its data. They don’t want to leak customer or employee private information, what they classify as personally identifiable information. They have a legislated duty to keep personal privacy information private, in fact.

Another legislated obligation they face relates to the public’s right to access certain types of information, classified under a freedom to information legislation. So they are required to make some information available when requested, and need to be able to locate and comply when a member of the public or press submits a request for details about something they have a right to be informed about.

This power utility has concrete information management requirements, all very well defined and documented at a corporation level. With their information types and policies defined at a corporate level, it made the job easier through the SharePoint Governance process since all the key decisions have been made. These corporate information policies map to implementation details, and our job was to capture what they meant to implement them in the SharePoint environment.

Some governance decisions we made involved acting on information classification requirements by enforcing users to classify required content in a few ways: by business impact risk and severity, like content that would affect future operations; the level of privacy sensitivity, like personally identifiable information; the degree security or secrecy, like plans or details that would be used in an attack; and whether it related to the freedom to information legislation.

Knowing we had to categorize content especially for these areas was clear since it was already decided at the organization level, well beyond the SharePoint initiative. This knowledge really defined the structure of the SharePoint content types and what metadata needed. Knowing the relevance of the different information types also led us to decisions about what other policies and workflows to attach to the content types. Without degreasing too far into a records management discussion, we were able to identify things like retention policies and the like, without a lot of analysis.

We got to skip the step of taking an inventory and analyzing all their content, since they already had a detailed list of requirements for each type of content. Taking advantage of this existing knowledge, we quickly translated those requirements into SharePoint features and slot in the implementation details quickly. This freed up cycles in the governance process to focus more effort on the end-user’s experience and awareness of the types of content they consume.

If a user is aware of the type of content and how sensitive it is, they’ll be less likely to pass it on to someone else and unintentionally create a security breach. When users accessed a piece of content, we visibly showed them the explicit sensitivities that classified the content. For extra sensitive or extra secure content, we changed the colour in the header. We even changed the background colour of an individual list item using XSLT in the list view, make it very obvious that it was sensitive before the user even opens it.

By making it easy for our users to know about the content they’re interacting with, we also made it easy for them to use the content in a proper and intended manner. Our governance plan was successful here because it took static requirements for content classification and translated them into actions we could implement and affect behaviour.

We worked tirelessly for a few weeks in back-to-back meetings, debating options, making decision, building a gold standard for SharePoint governance plans. At the end, I captured it all in a few documents that included a strategic-focused governance plan and a tactical-focused technical operations guide. We closed out the engagement feeling like we had accomplished a lot in such a short period, and we had.

Like any other consultant, eventually it was time for me to wrap up and let my customer swim on their own. This felt okay, because they had all the tools they needed: decisions were made, their direction was clear, and we captured all the details in the governance documents I delivered. I felt quite pleased with myself and the value I delivered, designing and delivering a new governance model in just a few weeks.

It felt so successful in fact, I often used them as my example to other customers when describing what’s possible with the right commitment and sponsorship. If they were prepared to make decisions and set priorities, I could guide them through the process, and they too would be set up for success. What’s not to like?

Imagine my surprise when a year or so later I was dialled in to a conference call with my government customer to discuss governance solutions. To be honest, I was actually a little speechless when they finished describing the challenges they experienced, challenges obviously related to governance. Of course my first question was around how we already solve all these problems. Yes, indeed, they confirmed everything we covered and neatly documented in the governance plan that sat lifeless in the original documents left largely untouched since I had disengaged.

So much for a “living document” or for delivering a governance solution. And quite frankly, I’ve seen this scenario repeated over and over with different customers and a variety of consultants. Consultants who deliver a valuable governance plan, but ones that are never acted upon. Consultants who are very capable and possess the expertise to produce excellent plans; but even still the initiatives fizzle after the consultants roll off their engagement and the customer files the delivered document.

It’s left me fine tuning governance ideas and reflecting on how to deliver a lasting governance solution in an engagement model that’s repeatable, and just as important, able to capture the engagement in a service delivery contract. One thing is for sure: the solution certainly goes beyond documenting a governance plan. Which makes it difficult because documenting a governance plan tends to be the key deliverable contracts are built around.

Why is this so common, and borderline trendy? The best I’ve been able to come up with is because it feels like something contained and predictable. It’s something consultants can wrap scope around to sell services, something that a talk at a conference can use to focus on concrete examples, something prescriptive that an IT organization can take as an action item.

But governance is more than a document that sits on a shelf. Governance is a set standards and processes that can be documented, yet just as importantly, governance is a set of behaviours and actions to take.

A good governance plan document sure helps though. I do like good documentation, and working through some of those Technet templates are a good place to start to get things rolling and point you in the right direction with what questions need answering and what decisions need to be made. I’m just stressing that this is only the first step: the beginning of an evolving process.

One key governance challenge is there is no one size fits all solution: every organization is different, has different values, has different maturity levels, has different needs, and has different user sophistication levels. This vagueness might also contribute to why it is easy to hit the “Easy Button” and simply focus on a governance plan template rather than rolling up one’s sleeves to tackle the larger governance opportunities.

I plan to use this area to post some of my thoughts and ideas on governance, in part because it will help me organize my own thinking and give me a reference to look back on. I also plan to feature some “In the Field” narratives of situations I’ve found customers in related to governance, both good and bad. Ideally somewhere along the way this might lead to a wider conversation where we can think through some of these challenges together.

Excellence is not necessarily efficiency. Though I love efficiencies, I care more about effectiveness. I am one for continuous improvement, but I never interpret that as a continuous compromise or a continuous diluting of quality to continuously improve short-term margins. In that triangle of tradeoffs, quality is clearly what I value highest over price and time. For some people, it’s one of the other two, and so the experiences they seek are much different from mine.

I even look for excellence when looking to enjoy coffee. One of my favorite coffee shops is one of the local Vancouver Caffe Artigianos – a fantastic local coffee experience with a few locations around town. Where a Tim Hortons or Dunkin Donuts might focus on price or time as priorities, while Starbucks might focus on premium mass production; Artigianos noticeably drives excellence in quality. It’s the smallest details that make the difference, but add them up and there’s excellence. Excellence is made by the refusal to compromise on details, whether someone’s watching or not.

A delicious mocha I enjoyed at Caffe Artigianos

They focus on the details in the entire experience: the bustling atmosphere, the yummy pastries, warming my cup with hot water before adding my drink to it, and even having glasses water available in line while waiting for my espresso pick up. These are all the little things that make the experience pleasant, and that’s over and above the product: a caffeinated beverage they’ve made beyond compare, taking their time to perfect each and every drink no matter how busy they are, even adding a fancy design with the foamed milk on top of every drink. That’s right, taking their time to do it perfect, no matter how busy they feel or how long line going out the door is. That’s excellence.

Maybe you know a coffee shop like this. They’re a pleasure to visit, the drinks are delicious, and the entire experience just stands out as something enjoyable. Part of the joy is the people working there. Everyone on the team is in sync, each one adding value to the value-chain, each one demonstrating their pride and commitment to excellence.

My pursuit of excellence has found several favorite places I frequent or products I enjoy. Imagine an IT solution delivery team that focuses on excellence, where every details is critically important, where there’s no compromise, where the whole team is committed and passionate about excellence. I know a couple that seem to aspire to get there, and maybe those aspirations will eventually be realized.

When I work on a technology solution delivery team where excellence is paramount, I find special motivation and drive in the project and with the team. Other teams that hold priorities like getting it done quickly or as cheap as possible certainly have a place and fill a need in the market, but for me when ever I’m on a team like this I feel like a fish out of water. I fit better on those teams that drive excellence as their priority.

Teams drive excellence and generate a high level of energy and passion around the delivery when quality is their priority, where a team’s strong and cohesive value-chain holds the keys to consistent excellence. When each team member and function are responsible for adding specific excellence, know what impact the excellence they add will have, and feel accountable to delivering excellence to the next link in the chain, then the collective will fire on all cylinders. The team will deliver excellence.

Someone on the team will splash some hot water in my cup to prep it for the espresso, making the subtlest change in the temperature of the final beverage, and the sum of all these little things add up to excellence.

As I look to the year ahead, there’s no doubt it’ll hold steady for me as my schedule is already looking good. It’ll mostly be a year where a lot personal projects and goals really come together and start to get wrapped up. That’s always exciting to turn new pages and chapters, and in some cases literally; but the tough part is staying focused and not getting carried away thinking about what comes after that.

Actually, as I alluded to in my opening, 2012 gives me the sense it’ll be a tough year for some, requiring focus and discipline from all. This new year seems like it will be a bit of a déjà vu of 2009. The global economy is pretty shaky, with many countries over leveraged with debt. Trends of governments scaling back spending will continue out of necessity. This will likely lead to plenty of political unrest throughout the EU, as they’ll be the hardest hit with drastic action in the coming months.

In the United States, political unrest isn’t as likely, at least not to the same degree as in the EU. Mostly because 2012 is an election year, providing an outlet for a catharsis, as US Americans watch the debates and get caught up in the election campaigns. The dangers here are continued polarized partisanship, lacking any healthy debate or progress for the long-term good of the American people, and instead continuing the tendency of stalemates and partisan political games. At least they don’t need to raise the debt ceiling until 2013, after the election and into a new term. Little drastic change in the US can be expected until then.

Low investor confidence and jittery speculation gives every indication that it’ll be another roller coaster ride for equities. Resources like gold should do well as is the trend to reallocate funds into these safer investments during turbulent times. Oil is expected to stay flat, with prices projected to be around $80-$90 per barrel. (Though, we all know how good they are at predicting the price of oil).

Locally for me and my market, Canada should hold steady, probably without much growth overall. The weaker price of oil will have a negative effect on the value of our dollar; combined with the government’s efforts to curb inflation in 2012 and their spending cuts to get the deficit under control will boast our exports and make Canada attractive for investment.

The downside for a services business is that governments across the board are cutting spending to get their deficits under control. Both the federal and provincial governments have already announced spending cuts, and more are expected. This slow down in government spending will match a slow down in corporate spending as they too brace for a tough year and feel the pressure to show earnings. If oil prices stay below $90 like they’re predicting, that traditionally comes with a slow down in spending in the energy industry too.

Indeed, 2012 doesn’t look to be a year of expansion and wild investment. Much like 2009, it appears to be a year to hold steady and focus on core business strengths. In my market, the major customers might not be looking to shed spending, but they’re also probably not looking for a lot of new things to invest in either (or soon won’t be).

My strategy is to focus more on the mid-market this year; to diversify with smaller, overlapping projects. This is a year to stick to my core and not burn cycles with any low-probability business development activities. But mostly, this is a year to invest in bringing some of my personal projects and goals across the finish line, positioning me well for 2013.

Findability is overrated. It is the idea that you need to think of all the ways that users might search for a given piece of content so that you can capture all the right metadata and store it in the right place. And this may seem logical, given how these crazy stats get quoted that apparently the average worker spends about a quarter of their workday looking for stuff. That’s a lot of productivity lost! Of course one would naturally want to make all that apparent searching more productive and help their users find all that content. It leads to this notion of making information more findable: if you put enough planning around the information architecture, there will be an explosion of productivity as users free up upwards of 25% of their workday from having to search for all this information.

It’s ludicrous, somewhat. I like the idea of connecting users to information, and improving that overall process. But instead of just making a faster widget, is there a way to enhance the whole process to get that desired end result? If it’s about connecting users to information, that can be a whole lot of things beyond one blinder-focused solution built around an anticipated search query. Besides, relevancy in searches is personal and in context, not simply preparing for what is considered a popular top query in any context.

What if instead of focusing on all the ways users might want to search for a given piece of content, the focus rather was on what content a given user might need at different times? Instead of the findability of content, let the focus be on the discoverability of content. A lot of the exercises and design may be the same: you still need to tag and organize content; the difference is the concentration in how the content will be used, namely what value it brings. Information discovery: how can the right information be exposed to the right user in the right context, at just the right time? (Maybe even without the user having to go searching for it).

I love Amazon, because they expose the right information to me in the right context, and usually at just the right time. When I open the home page, they show me different books I may be interested in, which often I am, and this satisfies me right away. Other times, there’s a book I’m already thinking about and do a quick search to find. While I’m reading a summary about this book, Amazon also suggests other similar books I may be interested in, and if I add it to my cart I get presented with other books that are likely to be of interest related to what I was shopping for during this and recent sessions.

Telemarketers use this technique as well when the caller’s computer updates their script depending on how the call is going. My account manager at my bank has offers on his computer prompting him to offer me different products and services at different times, depending on the context of what he is reviewing (although I always find it a little weird when I go in to withdrawal a roll of dollar coins to have change handy for parking and laundry, and this somehow leads to a discussion on whether I’m interested in a new mortgage).

Some companies and industries are well on their way with this focus. It’s no different really than having efficiency experts map the process on a factory floor around what adds value to tasks the workers actually perform, and bringing that concept to understanding what the knowledge worker does and what would be valuable information to make available to them, in what context, and at what time. The underlining technology is still search driven; the focus is just on the user’s experience and anticipated value interacting with the content: a focus on information discoverability rather than simply generic findability of a piece of content.

It turned out I had an infection brewing inside me just below my shoulder on my back, which probably explains why for much of this summer I had felt quite run down physically and my concentration didn’t feel as sharp as usual. Somehow one of my oil glands had got clogged, backed up, and this caused an infection to develop. It’s nothing too serious, I don’t think, but the doctor said she would have to cut in to drain and clean the infected area, and would go ahead and perform the procedure in a few minutes. What a treat: some nice surprise Saturday afternoon surgery!

After planning what she needed and freezing the area to prep, she made an incision. This was probably quite a routine process for her, so I was mostly focused on just waiting for her to finish. Here’s where the weird part happened: suddenly she reports to me that she isn’t finding the affected area and is going to close it back up and stop the procedure. Wait, what?

There I was lying there, with a couple inch cut in my back; I felt pretty committed to completing the task obviously, and she was committed until all of the sudden it was time to stop. Then I hear her say she found it, that she had cut a little deeper while she was deciding to halt the procedure and had found the infection; it was just deeper than she had expected. This really stuck out for me: she was ready to shut it all down and take a step back when she got a look under the skin and saw it may be bigger or deeper than she originally assessed. Stopping the procedure wouldn’t be a failure; in fact she said it like it was always an acceptable option that was perfectly okay or not at all unexpected.

Now in contrast, I’ve been on many IT projects, and these types of projects are hardly ever halted, no matter what the outlook for success looks like. There seems to be a stigma and unrealistic expectation that it’s not acceptable to halt an IT project, that doing so would mean there was a failure. Everyone from the project sponsor on down to the delivery team are conditioned with some dysfunctional commitment to seeing the project through, no matter what. I’ve been on several projects where I’ve sensed a disaster, yet even after raising a flag everyone still opts to stay the course. In September’s Harvard Business Review Magazine, there is an article that discusses exactly this, and they indicate that 67% of managers won’t shut down an IT project for their group, even when they know it is not likely to succeed.

It baffles me why I’ve known so many customers who decide to continue rather than halt a project, even when they know they have the wrong team or the project is heading way off course or the consultants they’ve hired seem to be coming up short. I wonder, is there a stigma that would make it feel like a failure if the project is simply shut down, so it is better to continue in hopes that somehow, magically, it will get back on track and recover? Or is the root cause that the procurement process is too difficult and adds too much overhead that projects tend to get defined by large generic contracts rather than contracting well to break it down into modules or distinct phases with a well-defined vision and clear expectations set?

Is it the existence of a contract itself that creates an environment of opposing sides to some degree that each have to remain mindful of protecting each of their own interests? Why would it be so easy and acceptable for a surgeon to end even a simple surgery before it achieves its original objective when things don’t turn out exactly as expected once they get a look below the skin, yet not so for an IT project? Perhaps contracts need a shutdown clause that defines the shutdown point up front before the project even initiates. I had the sense my doctor had a shutdown point in mind before she began the procedure, and this was why she was so prepared to stop and back out if something wasn’t as expected.

A healthy functional IT project considers a shutdown point before the project even kicks-off, and then checks in on that shutdown point regularly during status meetings to honestly assess how the project is trending in relation to when it should be halted. No more “Don’t ask; don’t tell” where there’s this unspoken commitment to continue no matter what, where the project blindly marches on to inadequacy and disappointment. Instead: regular checks against a perfectly acceptable shutdown point.

using System;
using System.Collections.Generic;
using System.IO;
using System.Globalization;
using System.Text;
using Microsoft.SharePoint.Utilities;
using Microsoft.SharePoint.Administration;
using Microsoft.SharePoint.Administration.Health;
namespace Develops.SharePoint.HealthRule
{
    public class UnpackagedFeatureRule : SPHealthAnalysisRule
    {
        List<string> unpackagedFeatures = new
				List<string>();
        #region Properties
        public override string Summary
        {
            get { return "One or more custom features was deployed without packaging it in a SharePoint Solution Package."; }
        }
        public override string Explanation
        {
            get
            {
                StringBuilder builder = new StringBuilder();
                foreach (string feature in unpackagedFeatures)
                {
                    builder.AppendLine(feature);
                }
                return string.Concat(
                    "The following custom features were not associated with a SharePoint Solution Package: ", builder);
            }
        }
        public override string Remedy
        {
            get { return "Package the identified Features into SharePoint solution packages."; }
        }
        public override SPHealthCategory Category
        {
            get { return SPHealthCategory.Configuration; }
        }
        public override SPHealthCheckErrorLevel ErrorLevel
        {
            get { return SPHealthCheckErrorLevel.Warning; }
        }
        public override SPHealthAnalysisRuleAutomaticExecutionParameters AutomaticExecutionParameters
        {
            get
            {
                SPHealthAnalysisRuleAutomaticExecutionParameters retval = new SPHealthAnalysisRuleAutomaticExecutionParameters();
                retval.Schedule = SPHealthCheckSchedule.Monthly;
                retval.Scope = SPHealthCheckScope.All;
                retval.ServiceType = typeof(SPTimerService);
                return retval;
            }
        }
        #endregion
        #region Check
        public override SPHealthCheckStatus Check()
        {
            if (!SPFarm.Joined)
                throw new InvalidOperationException();
            List<string> systemFeatures = new List<string>();
            List<string> customFeatures = new List<string>();
            FileStream stream = new FileStream(
                SPUtility.GetGenericSetupPath(@"CONFIG") + @"\builtinfeatures.txt",
                FileMode.Open, FileAccess.Read);
            StreamReader reader = new StreamReader(stream);
            string line = reader.ReadLine();
            while (line != null)
            {
                systemFeatures.Add(line.ToLower(CultureInfo.CurrentCulture));
                line = reader.ReadLine();
            }
            reader.Dispose();
            stream.Dispose();
            SPFarm farm = SPFarm.Local;
            foreach (SPFeatureDefinition featureDef in farm.FeatureDefinitions)
            {
                if (featureDef.SolutionId.Equals(Guid.Empty) &&
                    !systemFeatures.Contains(featureDef.DisplayName.ToLower(CultureInfo.CurrentCulture)))
                {
                    unpackagedFeatures.Add(featureDef.DisplayName);
                }
            }
            if (unpackagedFeatures.Count == 0)
                return
				SPHealthCheckStatus.Passed;
            else
                return SPHealthCheckStatus.Failed;
        }
        #endregion
    }
}
using System;
using System.Collections.Generic;
using System.Reflection;
using System.Runtime.InteropServices;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration.Health;
namespace Develops.SharePoint.HealthRule.Features.HealthRules
{
    public class HealthRulesEventReceiver : SPFeatureReceiver
    {
        public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            Assembly a = Assembly.GetExecutingAssembly();
            IDictionary<Type, Exception> exceptions = SPHealthAnalyzer.RegisterRules(a);
        }
        public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
        {
            Assembly a = Assembly.GetExecutingAssembly();
            IDictionary<Type, Exception> exceptions = SPHealthAnalyzer.UnregisterRules(a);
        }
    }
}