Watch the Scope: Who Can See What

When using or deploying a social networking application, it's very important to ask the question: who can see what. We deployed an items of interest reporting tool where each report was made up of individual activities. That was cool because the tool allowed users to search and tag individual activities. But most people come from a back ground where these IOI reports are private to the group that reads them or the person the reports are submitted to. So, they just assumed that the activities in this new tool did the same thing. Not so. Everyone could see the activities.

So when deploying a tool, ask the question: given each object the tool manages: wiki's, blogs, documents, activities, bookmarks, etc - who can see what by default. In today's social networking tools the bias is to make everything as accessible as possible. However, most users in the enterprise have been using tools that are closed by default. That's a very big change and can create some serious problems.

Don't Ignore the Auditor

Every large organization has auditors who monitor the software development process - what work products will you create, how will you capture approvals, how are changes documented, etc. In the midst of the battle, these guys will seem like a waste of time - picking at this and that when you've got WAY bigger issues to solve. The temptation is to ignore them.

The problem is that they've usually got the ear of someone higher up - and usually it's the whole reporting chain between you and that higher up. They have the ear and aren't afraid to use it, even for trivial issues. You may think it's a waste of the higher up's time and yours, but there it is. You'll just have to suck it up and do it. Don't hesitate to delegate these kinds of tasks. Their usually not hard (exactly the reason you hang on to them).

Pain in the neck? You bet. Waste of time? Probably. But you need to stay off the radar

Is It Really COTS?

In large corporations there are typically many IT development efforts going on all over the place. At some point an executive will see a solution for a department or local business and want it deployed to the wider organization. The logic runs something like this: they got it to work in their organization, I should just be able to install it for the enterprise. This sets the expectation that the solution can be deployed in a couple weeks if not by the end of the month. They think of it as Commercial Off the Shelf (COTS) - kind of like installing MS Office.

And they couldn't be more wrong.

If the solution is a small tool or simple web/db application, then it will probably go smoothly, but even here, enterprise wide deployments magnify problems. Some key questions to ask:

What are the key components that make up the system? Is there documentation that shows how these components talk to each other? When there's a problem, knowing these flows is critical.

Testing is everything - having a good test plan and test environment is important. Just because it worked there, doesn't mean it will work here.

Help support - when someone has a problem, who do they call? Do they call a company help line? If so are the tier 1 and 2 support people trained in the product?

Know what you deliver. This seems strange: management says 'take that thing over there and make it available over here' but does management and those stake holders 'over here' know what the product is? They'll say they want it, but do they know what it is? Document the functionality and get sign off from stake holders.

Testers

Having good testers on your team is critical. Here's what makes a good tester:

Writes everything down: error messages, steps, etc. I mean EVERYTHING.

Good at informal testing: able to run with the system and find issues.

Attempts to isolate the problem. They go beyond just saying the test fails.

Good at defect tracking - systematically documents defects. Doesn't announce every time there's a defect.

The test lead pulls in people to review defects. Doesn't just declare a defect and hopes that someone will deal with it.

A tester needs to be humble and not gloat over problems.

If tester finds something majorly wrong, they don't make a big deal about it - no drama, no blame. Other people are paid to do that.

Good testers are hard to find!

Team Content Gardener

I had someone suggest the other day that our team should have a content gardner - someone to organize team content, develop play books, educate on the use of blogs, setup standards, etc. Here's why I don't think this is a good idea:

This is counter web 2.0. One of the driving forces behind web 2.0 is user initiated content organization and sharing. Tagging, blogging and wikipedia applications are a perfect example of this. Tagging came about because we all got sick of that other guy who thought he knew how to organize everyone else's taxonomies.

If there are issues concerning how the team is using it's social networking tools, it's up to the team to communicate and this needs to start with the leadership of the team, but also needs a team that initiates dialog.

The team needs to know that reminders are okay. We're all super busy and can drift into old patterns of doing things. Reminders given in the right spirit build trust and help the performance of the team.

Consultants are good. If the team can bring in someone with an outside perspective on how to leverage social networking tools, that's a huge plus. It's up to the team to internalize these suggestions and practices. The consultant needs to realize this and go away when the consulting is over.

Those doing the work will have greater insight into how content should be organized.

There are exceptions to this rule. For very large programs, a content gardner may be just the thing. Pick you gardner carefully. Some people get hooked on the power they get by taking control over other people's content - you don't want that person. Also, mistakes are okay. There are not a lot of people that really know how to do content gardening - give them a chance to try new ideas out.



The bottom line is that teams need to internalize best practices. The team that realizes that it needs to take time to dialog about how their using the tools, will be the more productive team. Team leads need to make time to talk about how to organize content and make sure that their folks will be assessed on how proactive they are in this area.

Stupid Requests

I got a stupid request today - someone wanted an architectural diagram so that they could figure out something concerning disaster recovery. For this person, it was kind of like saying, "I need to find a coffee shop in NY City, can you give me a detailed map of the water system, I mean, you need water for coffee right?" I said something witty and scornful and moved on.

Here's the problem with the word stupid, it's a loose-loose word. The person it's direct towards now feels pissed off, shamed, etc And I've just feed my big fat ego. It can get even worse - the person doing the asking may be stuck in the middle and now has to satisfy someone who doesn't know what their talking about with someone who's being to knuckle head. Both accomplish nothing.

But here's the crazy thing: these are great opportunities - their easy! All I have to do is send a diagram and tell them if they need help, let me know. That's it! Sure you and I can see the problem a mile off, but who cares? We've engaged in a dialog (good thing), offered to help (good thing), and they get something to start thinking about (good thing).

So, loose the attitude and use the opportunity to foster a dialog.

Making Sure They Connect

As a project lead, probably my most important job is simply to make sure people are talking to each other. I've found that it's best to treat this as normal business: no hysterics, no beating people up, just simple, 'have you talked with so-n-so?'. Since project leads have the big picture of a project, they tend to have a good idea of who to talk to.

Here are some reasons people get stuck:

• They don't know who to talk to.
• They believe their part is done. We get stuck in our own little world and forget systems have pieces that need to come together.
• They sent an email and didn't hear anything back. We rely on this one too often.
• They have bad information. Someone told them why it doesn't work and their waiting for a fix, when in fact it's not the reason they were given.
• They don't have the power to speed things up. This is where the project lead comes in. Sometimes a word from the lead or escalation, and things get moving
• They get lost in the weeds - too many things going on, and they drop the ball. Just need a reminder or some quick help.

So to help, the lead needs to start with a status question. If it isn't moving, then ask, who have you talked to, or who are you waiting on. Simple follow the lines of communication.

These issues are amplified on virtual work teams and project leads needs to be more diligent on this issue. It would be nice if everyone would follow through, but often times reality is something else.

So, make sure they connect!