Business Planning, where is the real value?

As we finish up this year’s business planning process for Advanced Decisions I look back at all the discussion and ideas debated. As with any practical plan, not everything desired could be included. There remain some pretty good thoughts sitting on the sidelines waiting for their moment.

We see many threats that can and will impact our business. Not the least of which are the current global economic turbulence and continuing tight labor market in certain areas.  However, having a plan that includes realistic threats and risk mitigation strategies allow us to approach the new fiscal year with a sense of optimism and confidence.

The value of our Business Plan is that we can visualize how to achieve our goals.

Did Apple Set The Standard Again?

Macworld 2008 is now in the books. Some stunning new products were announced. For a company that is no longer a "computer" company it does a pretty good job of disguising itself. Perhaps Microsoft/Dell should take notice.

For me, the new MacBook Air is a beautiful product.  It is a true portable that embraces wireless. Finally having the option of a full sized keyboard and reasonably sized screen in a remarkably thin and lightweight package will set a high bar for portable notebooks. A docking station is no longer needed; I only see the need for two cables in the office. One cable is for power and the second for an external monitor. WiFi and Bluetooth wireless connections for the network and mouse/keyboard eliminate the need for additional cables.

But for me the most significant product announcement is the new Airport/NAS or Time Capsule. The combination of software (Leopard’s built-in Time Machine) and wireless hardware make automated backup a reality.  There is simply no reason for us not to have our digital life stowed away safely and inexpensively. But best of all, instantly retrievable.

I am confident that the PC community will catch-up, but non-Apple users will have to wait until Windows 2009 . . . is released.

Happy New Year

After a prolonged absence, I am back.  Writing, for me, is difficult. I find myself doing almost anything to avoid it. This is not a good formula to become an active blogger. Something needs to change … me.

Effective communications is essential to most every job. And it is especially so for a consultant. Gathering and writing requirements for the next project is at least as important as the system architecture, design and code. I believe that regular writing in any venue will improve writing in all areas.

The blogosphere is full of serious writers, reporters, journalists and just plain ordinary folk who have something to say … hopefully something interesting. I plan to fit in the latter category.

I look forward to hearing from you. Please comment, criticize, question; let’s create a dialogue.

The Dangers of Micro-managing

What’s one sure way to get the least out of your team? Micro-manage them. I’ve seen this again and again – Micro-managing, or supplying every little detail and expecting every little comment you make to be executed literally will quickly shut down their brains.

I saw this with one of our consultants. He was working on a project where the manager had very specific, non-explicit requirements for how the solution was implemented. After two or three of his suggestions were shot down, he stopped making them. The funny thing is that his suggestions would have made the product more robust and maintainable. Even more interesting than that, this senior developer started asking me how to implement specific lines of code. I have not coded in 10 years, but I understood why he was asking and what he needed. He wanted to give the customer what they wanted, and knew they had very specific ways they wanted it coded.

Thinking about my own management style, I think I may err too far in the other direction. I’ve been told, more than once, that I have made my directs uncomfortable because I don’t tell them exactly what to do. I do try to make sure they know I have confidence in them, and that I’m there if they have questions, but sometimes it still seems like they’d like very specific direction. My question is: Is this just because they have become used to being micro-managed, or is there a middle ground that I’m missing?

Virtual Development Teams

Sometimes when I read about trends, I wonder if they are “real.” How many people are actually doing it and is it working for them? I am getting to see one trend in action more and more often lately – virtual development teams.

I’m working with a few companies that are completely virtual – no one works in the same physical location. Right now, I’m even looking for a developer to work with one of these teams. One of the many benefits of this arrangement is that we can look anywhere, and I do mean anywhere.

I’ve managed individuals that worked in remote locations, and teams that were in multiple locations, but never a team where no one was co-located. The most interesting thing about this engagement is that the client is ok with not meeting the developer. I’m not sure I would have been but in this case I can see why. They are looking for someone with Open Source experience. They’ll be able to see real code this person has produced, and see how this person interacts with another virtual team. This is so much more revealing than the typical (or even a good) interviewing process.

The broader implications of this are fascinating. Are we really moving towards a true talent market where we can work with the best of the best, from anywhere in the world?

Is your technique working?

I've been working on improving my sales skills, and one thing I've been reading a lot about is “Question Based Selling.” It says, engage your prospect in conversation, earn their trust, and learn about their issues before proposing anything. Makes sense.

So I was at a trade show yesterday, wandering the floor and wandered into a booth and asked the man there to tell me what his company did. He gave me something very vague then asked me a series of questions about my company and past experiences.

I answered quite a few of them before I realized that he either did not understand me or was not listening to me because the follow-on questions did not make sense. I finally asked him again if he could tell me what his company did. He replied again that the did many things, and at this point asked me if it made sense for us to meet and continue talking.

By this time, I was a little annoyed that he would not answer my questions and my first reaction was “no it does not make sense for us to meet.” It was not until later that I realized that he was probably new and probably asking the questions that he had memorized, but the key was, that his technique was not working. I think that’s an important observation whether you’re selling, managing people, or developing software. Know what’s working and what’s not. In order to do this you need to pay attention to the results you’re getting. Even the best technique does not always work and we all need to be flexible. Have plenty of tools in your toolbox, and use them wisely.

Part 2 -- What can you do when a project goes terribly wrong?

In my previous blog I recommended steps to follow and pitfalls to avoid once a project is in trouble. Now that we have a strategy for change and have management buy-in, it is time to take action.

It is best to start by assembling the entire project team and communicating the change strategy. In order to turn-around a failing project effectively you need buy-in from all the team members --- even those not directly involved in implementing the change.

The project plan and schedule needs to be revised and shared with all team members. This is a good time to ask a few questions. Do we have enough or the right resources to move forward? Do we have the right tools? One common outcome I have noticed with projects that get into trouble, is that the original project team did not have the appropriate level of expertise in a new technology. To turn the project around you may need to add a temporary resource with special skills. Find this resource(s) - fast! Get the right tools. Then update the schedule.

Once the Team is assembled, start at the beginning. Review Requirements, Architecture, Design and Test Procedures, in that order. Make necessary modifications before starting development.

As you can see there is a lot of legwork before you can effectively change the course of a project, but you must do it for the project to be successful.