Silence is Golden

Was on a call with a group of directors reviewing a presentation for some set of functionality to be delivered and the discussion was heated and lively. At one point I IM'ed the technical lead and asked what she thought - she'd been pretty quiet. She sent back: with so many geniuses on the phone, I don't think I'd have anything of value to add ;-)

You know, the temptation is very high to jump in and share your mind. but sometimes it's just better to be quiet.

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!

Project WBS: Product or Task?

With social networking solutions evolving rapidly, the reality is: you're going to be doing this again and again. You're not going to deploy one wiki/document management/discussion forum/... solution that will last for the next five years. So here's the project management challenge: estimating the next effort. To accurately estimate the next effort you're going to need to track actuals for your current effort, and to do that effectively, you'll need a good WBS structure. So do you use a task or product oriented WBS? Many WBS' I've seen are task oriented, where they are broken down by planning, analysis, design, development, and deployment. The problem with this approach is - it's not reusable. If I track how long it takes the team to do requirements analysis - so what? Requirements analysis for the deployment of an integrated suite of commercial (COTS) tools is way different than deploying a home made wiki tool. But, if we track how long it takes to do a wiki tool, whether it be home made, COTS, etc., then we have something we can reuse and compare. And that's why you should use a product oriented WBS, instead of a task oriented one. Large IT organizations can often have planning and estimating groups. I'm not sure why it is, but some of these groups can resist the use of product oriented WBS. This makes estimating almost impossible for later projects. Push for the use of the product oriented WBS, it'll make your life easier later when you have to redeploy part of your collaboration solution. And you will be doing this again!

Think Partnership

We've all heard it: the customer is always right.

This seems counter intuitive to our daily lives - we tend to react negatively when someone says that so-and-so is right because of their position or office. We laugh when we hear things like, father is always right. We get scared when a preacher says he's always right (think cult). And we get ticked off when our manager thinks their always right. So why would we assume a customer is always right?

The customer is certainly paying and the customer certainly has needs. In fact the customer probably understands the problem better than anyone. But is the customer always right? The Guru Red Manifesto talks to this by saying that the customer is negotiating for a position that wants it free, perfect and now. This is over the top language, but does highlight a reality of working with customers.

We also see this in organizations were customer service is separate from engineering. Customer service will be driven by customer dates and needs (a good thing) and engineering will be driven by what they can do and have resources for (a good thing). The right answer is to negotiate to the needs of both. The problem is when both organizations see themselves as more important. The customer service groups says, 'this is what the customer needs', and engineering says, 'we can't do that'.

The successful deployment of a system always involves four things: Design (branding, navigation, customer experience), business (ROI, risk, cost savings), technology (programming languages, standards), and process (program management, development life cycle). Here's the thing, none of these are automatically more right than the other. Each of these will negotiate with each other and the key to good negotiation is to know the needs of each other. For an excellent book on negotiation, see Getting to Yes, if you can, get the audio version. Risk management also becomes important here, for example, a highly visible enterprise wide system will have a greater impact if each of these core areas aren't addressed.

Someone needs to make visible what's on the plate and it might as well be you. Make a list of projects and have a clear description of the purpose, deliverable, resource requirements, and assumptions of each. Get concurrence on priorities and status each project as: not planned, planned, in progress, etc. Engineering or customer service - someone needs to do it.

So the next time you hear, 'the customer is always right', or '90% is customer and 10% is engineering', be prepared to address reality, and manage this as a partnership.

Canned Signature

Do you have a "Regards, Pete", "Sincerely, Pete", etc. in your default signature block? If yes, get ride of it. This is like wearing a button that says "Thank you" and telling your Mom it's okay.

It won't take you but another second to put on the appropriate regards - if you even need it at all. Emails don't need to always be like a letter, "Dear Jack, ..... Sincerely, Pete". Just say what you need to say and make the closing fit the tone of the email.

Be human!

Blogging Status

For many people in the enterprise, blogging seems like domain of larger than life experts, slackers or freaks. The key is to show them ways that blogs can be valuable in a business context.

One way is to use blog postings to let people know the status of some effort - we've installed the code and are having a problem with IP addresses, we've completed the requirements document and will have a review on Thursday, etc.

This addresses the problem of having too many meetings and in a virtual environment, this is even more so. As projects progress and more tasks are in play, program management wants to know what's going on. This can result in more meetings to get status. If team members are blogging about status, and program management is watching these, then the status information will be available.

I've found that having a common team/project blog meets this need, where anyone on the team can contribute.

This does require trust, and that trust is enhanced by systematic blogging. Also, the players need to have a good relationship, which is the responsibility of team leads to foster and grow.

Virtual Calendars

Teams that don't work in the same location rely on tools like MS Outlook to setup meetings. The problem with tools like this is that it creates the illusion that I'm available whenever there isn't a meeting schedule, and beyond. People will schedule back to back meetings all day long, all week long and that's not good on productivity. In fact what starts to happen is that since there's no time to really get things done, people will schedule meetings to get things done. Don't have time to get that document done? They'll schedule a meeting with you and three other people to work on it. No wonder people hate meetings.

So here are some things I've found helpful:

You need time to get away from your desk - if you do this during lunch, create a recurring meeting for lunch. While there will be times when you'll need to schedule meetings during this time and you can negotiate as needed.

Some meetings require that you debrief - you need time after the meeting to review action items, summarize results, etc. If someone sends you an appointment for a meeting like this, schedule 15minutes after that so you'll have that time.

Sometimes a meeting needs prep time - 15 to 30 minutes to get ready. Schedule an appointment on your calendar to do this prep work.

You need time to do email. Email is another whole other set of blogs, so for the purposes of this discussion, let's just say that unless you're in customer service, you can't let it interrupt you all day long. Create yourself a recurring appointment to review email. I schedule 3, 1/2hr appointments each day to review email.

One of my team members has a tough commute in the morning which means that he gets in around 9:00 and he blocks that commute time out. The lesson here: be realistic - block it out if you aren't going to be there.

Block out family time. I've had people who scheduled meetings way after normal working hours. Your family comes first and you need to protect that time. In most situations I find that people respect non-core work hours and that this has only been a problem on occasion. All this ties into another discussion about how to communicate work practices - another couple blogs on this one!

I block out time on Friday to clean out my email box, review tasks for the week, and plan for the start of next week.

Really the burden is on me to manage my schedule (and you for yours). I've got to have time to do my work. We can't let the disorganization of other people create a crazy week for us.

Work anywhere virtual risk

With the cost of living, cost of office space in cities, and the price of fuel, many organizations are moving to virtual works forces and telecommuting. Makes a lot of sense. My observation is that productivity of works can go up - with the office in the home, more workers are willing to put in more hours. It also helps the family -kids are able to see Mom and Dad working, commute time is converted into family time, etc. Big plus. Virtual workforces have their issues, but these can be managed in most cases.

I know people that have taken the opportunity to move to places that either open up opportunities (ex: dream to live on a ranch) or to live in a place of their dreams.

But then something ugly happens: the economy takes a down turn, a company releases workforce, and now you need to find a job. If you live in the middle of no-where, your job opportunities may be no where as well.

So, pursue your dreams and be realistic.

Personal Networking

Great collaboration systems are deployed by great teams that have great people. It's that simple. And to put together a great team you have to have a great personal network. The goal of personal networking is to get a list of people (anyone and everyone you can), that you stay in touch with (every three months), and that you constantly scan for opportunities to give to (vs. being a blood sucker and looking for how you can use them). The best resource on setting up a personal network is the podcast from Manager Tools - 5/8/2006, Building a Network. Listen to the podcast, then do the following:

• Everyone you meet, not matter their position, add to your contacts list in Outlook. You'll need people in your company and outside. Do everyone!
• Create a category called @Network in Outlook
• Create a task with that persons name and email address, make it a recurring task every three months and put it in the @Network category.
• When the reminder pops up send that person an email: "Hey, just wanted to say hi! Hope all's well with the family!" Tack on some question about their job, family, project, etc - show some interest!
• When they respond back, take their response and put it in the notes section of the contact entry in Outlook so you'll remember what's up with them.

Here's the thing: when you're working with people you think (or don't think as the case may be) that these people will always be around. They won't, so get them in your network today, so when they move on, you'll stay in touch.

I wish I had started this in college or when I started work. If I had, I would have 26 years worth of people in my list. When I started three years ago doing this, it was actually fun. I started to think through all the people I've worked with and started to get back in touch with them - very cool. In some cases it was funny, I had one person who thought I was after something! They calmed down and we've been in touch ever since.

So here's why this is important:

• First, showing regular care to other human beings is important. Really don't need any other reason. The list could stop here. They feel valued, you keep up, and it's fun. It forces me to think outside of my immediate circle.
• Second, they may need help and you can either offer that help, or hook them up with someone else. Just had a guy call me in a layoff situation. If I hadn't been doing this networking thing, he wouldn't have that opportunity. Not someone I normally would have networked with.
• Third, I may need help someday. I may get laidoff, or need help. And I may need some people to deliver a great collaboration system.

What's it about?

So what's the blog about? This blog will cover all things concerning the deployment of collaboration systems - everything from program management, scheduling, team dynamics, types of collaboration products, architecture considerations, future directions, etc. In other words, the whole enchilada!

I work at a large company and have been involved with the deployment of different types of collaboration systems ranging from content management solution, process asset libraries, document management solutions and social networking tools. I run into new stuff every day and wanted to share some of those experiences.

Enjoy!