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!