Tuesday, May 05, 2009

Rewind: The 12 Secrets of Successful Project Management

Last week I did a webinar with Autotask on The 12 Secrets of Successful Project Management. There were several leftover questions. Since many of those questions had to do with where to find my books, I thought I'd post the answers here.

If you're interested in the original webinar, check out http://www.autotask.com/events/archive/KPEnterprises_042809.htm.

Note: During this webinar, we gave out a code for a free copy of the Managed Services in a Month MP3 AND a code for $10 off at SMB Books. If you want those codes, you need to watch the webinar.

These are some of the common questions I get a lot, so I thought it was worth posting here.

So here are the leftover questions and my responses. I left them in the order they appeared, so the first few are about books with links. Then it gets into more "meat." Be patient. Thanks.


Q: Can you post the title of that book please?

A: My project planning book is the "Super-Good Project Planner for Technical Consultants" available at the electronic downloads page at http://smbbooks.com/categories/electronicdownloads.htm.
Also check out the audio program "Perfect Profitable Projects" with Karl W. Palachuk and Matt Makowicz. This 3-CD set includes two audio CDs plus an additional electronic content CD. See http://smbbooks.com/categories/audiocds.htm.


Q: What's your methodology for documentation and organizing it.

A: This is a big question.

For documenting client machines, we have two methods. Our primary method is to use the forms in the "Network Documentation Workbook" (see http://smbbooks.com/categories/electronicdownloads.htm). This gives us the key information on computer configurations, network setting (DHCP, IP scopes, etc.), and all the specifics that are needed quickly while onsite.

The second method is to use our tools - Autotask and Zenith. We even store a scanned copy of the network documentation binder in Autotask as an account attachment. We store as much as we can here. For example, license info arrives from Microsoft. We save this as an attachment. And of course we store specific configuration info in the configuration tabs in Autotask.

We document processes and procedures in Word and store them on our internal SharePoint site. The key here is to have a logical organizational structure, make it as simple as possible, and make people use it.

For detailed discussion of using documentation to make money and save money, see the audio program "Network Documentation for Profit (and Fun)" at http://smbbooks.com/categories/audiocds.htm.


Q: Does Karl have any books that outline best practices of documentations?

A: "Network Documentation Workbook" (see http://smbbooks.com/categories/electronicdownloads.htm).
- "Network Documentation for Profit (and Fun)" at http://smbbooks.com/categories/audiocds.htm.
- "Service Agreements for SMB Consultants" at http://smbbooks.com/categories/business_IT.htm


Q: Nice to have, but in some cases, like software development, the scoop can't or shouldn't be defined in a rigid manner, especially when dealing with user interfaces.

A: Software development projects are a little different. But I can tell you that I learned most of my project management process from software development. If you're not rigorous about the scope, you'll have hobbled-together project when you're done. You'll be over budget, over time, and not have the best piece of software you could have.

Clients always want to cut out the stages for discovery and scope development. So they save $10,000 or $20,000 up front and waste $100,000 in change orders.

Yes, it's rigid. But the scope is the project. Period. If the client is happy to have a big undefined section that says "Whatever comes up" and puts money into it, then you're good to go. But if money matters, then scope matters.


Q: How do you deal with projects that have such complexity?

A: A: By "such complexity" I will take the example of the always popular Network Migration. We handle major project like this by dividing and conquering. How does an ant eat an elephant? One bite at a time.

Everyone does network migrations, even if they don't do much planning. The way to get started with organizing a large project is to walk through it in your mind and pencil out what you'd do. You have to either move or re-create computer accounts. You have to migrate the domain control (FSMO roles). You have to move DHCP. Etc.

List everything that needs to be done. If you already have checklists or stored Autotask templates for processes, then you can start by collecting these. After all, a big project is just a big collection of smaller checklists.

In our Zero Downtime Migration process, for example, we only use seven stages. And two of them are client training (before and after). The rest are big, manageable chunks. Move the data. Migrate the desktops.

In the end, we have a 130 page checklist. Yes, it's rigorous. But it's not difficult. While higher skills and higher knowledge will make things go faster, there are no processes in a network migration that require higher-level consulting. On really complicated migrations, you'll need some higher-level engineering. But execution of the plan is just a matter of taking it slowly and being careful. Remember: Slow Down, Get More Done.

We believe the "Network Migration Workbook" Will be available in June.


Q: Great for non-innovative projects that include well-defined tasks, but terrible for projects that involve innovations.

A: I'm not sure what this means. One can't really argue that lack of planning, lack of preparation, and lack of execution makes for a better project. Think about the most innovative people and companies in the world: They're rigorous about development processes.

Take, for example, Intel or Google. As big as they are, do you think they let engineers waste massive company resources repeating the same failed innovations again and again? No. They document everything they do. They innovate in a systematic way to maximize success.

I don't mean to downplay the role of inspiration or creative thinking. But I've sold millions of dollars worth of innovative projects that were successful because they were properly managed. I can't count on luck every day. I CAN count on good, repeatable processes every day.

Remember, this presentation began with a nod to Michael Gerber's book The E-myth Revisited. Innovations that are applied in a systematic and repeatable way become the largest and most successful franchises in the world.


Q: But what if they are things that came up as a result of project work?

A: Let me give two answers.

Answer One. If things come up "within" the project, they are recorded. Service requests are created. It is extremely important that you do this so nothing gets lost, dropped, or forgotten. There are only three things that can happen to these items.

1) They are made irrelevant by the success of the project. For example, if someone can't get to the internet and the project is to upgrade the firewall, that issue may be resolved.

2) The request may be so small that it is simply included in the project. For example, you're doing a company-wide upgrade to Office 2007 and someone asks how to create a signature in Outlook. You create the service request. If you get a whole bunch of these, you'll do a training and perform the work outside the project. If you only get one, you'll spend the 15 minutes and roll it into the project.

3) The most common disposition of a new request is that it is outside the scope of the project. A separate service request (service ticket) is created so labor can be billed against it. This keeps the scope intact and keeps the project profitable. When possible, you'll want to push this labor to after the project, but you don't necessarily have to do that. If you perform this work "during" the project, you simply stop billing time against the project and bill time against the new SR.

In all cases, the work inside the scope stays inside the project and the work outside the scope stays outside the project.
Answer Two. If things come up as a result of the project, they are almost always performed after the project is complete. For example, in a desktop cleanup sweep (project) you discover that the company-wide hobby appears to be running small businesses from company computers (real estate, ebay sales, bridle planning, etc.). You contact the owner and recommend tighter controls around web and email.

What you've done is to define a new project.

It is not okay to interrupt the current project to address the new project. Finish what you're doing. Have success in the job at hand. THEN move to the new project.

Remember, you're two most profitable phrases are "That's inside the scope of the project" and "That's outside the scope of the project." Of those, the second is the most profitable.


Q: Can you touch on project issues vs tickets (outside of scope)?

A: I think we've covered the "outside the scope" stuff pretty thoroughly.

But the reality is that some things come up that are inside the scope. "New" stuff that's inside the scope only happens if your discovery process is wrong or incomplete. It could be either of these because you did not have a good process, because the client did not cooperate, or because someone gave you wrong or incomplete information.

Stuff happens.

Perhaps the most common example of increased labor inside the scope comes from a quote that says something like "Move all data to the server, organize, and remove from desktops." Without proper discovery, you didn't know that each person in the marketing department has a 250GB USB drive filled with "critical" company graphics and videos. Now, no matter how long it takes, you've including moving and organizing that as part of your project.

Stuff happens to you. :-)

Another example would be a company-wide Word template that must be installed on all new machines in order to enforce standardized fonts and formats. You didn't know about it because you have installed a new machine at this company and the template is rock solid and never causes issues. The client forgot about it and you didn't discover it. Result: 10 minutes of labor per user unless you can configure via Zenith script or group policy.

You can never have perfect discovery. But you can have extremely good discovery. Our Zero Downtime Migration process includes more than ten pages of "pre discovery." That's the process of making sure you've listed all the stuff you need to go discover! If the whole project is four hours, then a massive discovery is pointless. But if the project is fifty hours, or involves mission critical systems, then the more discovery the better.

One final thought on this topic: Sometimes you do on the job training. I know that's sacrilegious. But let's say you've never moved AllScripts to a new server. How do you do it? Well, you start by making sure the client has support. You call the support line. You get educated. You create a process. But until you experience it, you don't know for a fact how long it will take or what the factors are in making it go faster or slower.

Your quote needs to include a statement that you assume the project has support and that you'll have access to that support. As Erick Simpson loves to preach: you should be managing your clients' vendors.

You also need to begin all labor quotes with "Estimated labor to . . .." That way, if you need to go back to the client, hat
in hand, you can say you just didn't know it would take so long.

Some days you give away a few hours. The better your discovery and documentation, the fewer hours you give away.


Q: How do you estimate time on aspects of a project? For instance, the first time you configure an Exchange 2007 server, each step will take longer than if it's your 10th time.

A: Len D. made an excellent point in the webinar: If you can practice the key process on your own systems with NFR software, that will give you both an education and experience. One of the key points I make in the "Perfect Profitable Projects" audio program (Karl W. Palachuk and Matt Makowicz. See http://smbbooks.com/categories/audiocds.htm) is that project estimates go through a cycle of accuracy. New products and new-to-you projects have no real baseline. Accurate estimates only come with experience.

If you have an analogous experience (e.g., you've configured an Exchange 2003 server), you can start with that. But you need to add a safety measure. You don't know about database conversion speeds and you won't be familiar with the new tool Microsoft recommends for the job. Checking out the relevant vendor blogs can be very helpful. They may even answer your questions. Microsoft is pretty good about this kind of thing.

Do the best you can. Add a little padding. And don't forget the human side of things: Talk to the client. Over Freakin' Communicate. Tell them that this is just an estimate. You might come across database issues. You may need to revert to older tools. Etc. Your clients are rational business people who know that neither you nor the software vendor are perfect.


Q: Are there binder type templates available in Autotask?

A: Project templates can be created and shared between users. Right now there are no binder type templates built in to Autotask. We are exploring how we can integrate templates so that you can enter data into Autotask projects and print out pages that very much like those in the "Super-Good Project Planner for Technical Consultants" (See http://smbbooks.com/categories/electronicdownloads.htm).


Q: You spoke about opening Tickets for outside-of-scope events. This moves hours and work tracking off the project. What suggestion would you give if you needed to keep the hours and work ON the project. We have started exploring the project Issues feature

A: If you want to create new tickets inside the project, you are, by definition, changing the scope of the project. This requires two things. First, you need a quote and approval for more money. Adding labor to the project adds costs. Period.

Second, you need to be very clear with the client about the revised scope. Don't let the job devolve into a project with no boundaries. Without limits, it will never be finished and the client will never be happy.


Q: What is the code for the MSP in a month book?

A: Managed Services in a Month. As announced in the webinar / slide deck. Please see webinar.


Q: What is that MP3 MSP book code?

A: Managed Services in a Month. As announced in the webinar / slide deck. Please see webinar.


Q: Where to purchase Karl's Network Documentation Workbook

A: "Network Documentation Workbook" (see http://smbbooks.com/categories/electronicdownloads.htm).

- - - - -

Thank you, Autotask, for the opportunity to present.

Thank you to the 300+ people who attended. I'm sorry we didn't have another hour!

:-)



Visit www.smbbooks.com
Books - Audio CDs - SBS - and more!

No comments:

Post a Comment

Feedback Welcome

Please note, however, that spam will be deleted, as will abusive posts.

Disagreements welcome!