July 18th, 2007

INTERVIEW: Colby Thames (President - On Demand Delivery, BSG)

Posted by Michael Krigsman @ 2:02 pm

Categories: Enterprise 2.0, Interview, Vendor relationships

Tags: Michael Krigsman

Colby Thames has lived in the world of traditional consulting and large account management for a many years. At SunGard Data Systems, he was responsible for the company’s largest accounts, and before that he founded a consulting company and worked for Ernst & Young. However, what really caught my eye is Colby’s present position, President for On Demand Delivery, at BSG Alliance Corporation.

BSG Alliance is trying to re-shape the traditional systems and business consulting in a way that reflects the latest tools and techniques for reducing project size and keeping project risk low. Based on this backdrop, I asked Colby some questions to help us understand what his company is doing to reduce failures on software implementation projects.

1. How does BSG’s consulting delivery model differ from more traditional approaches?

BSG helps its customers drive business innovation through use of technology. As a result, our projects are typically highly strategic, often serving complex businesses in situations where packaged software doesn’t exist or is inadequate to meet our customers’ needs. Traditional consulting delivery tends to be overly-focused on driving billable hours rather than delivering business value to the customer. We’ve invested substantial resources to construct a model addressing this shortcoming in the traditional approach.

Earlier this year, we acquired a business strategy consulting group, BSG Concours, as part of our effort to build a new type of consulting model. This acquisition gives us the real capability to define and drive business value, executing projects with high strategic importance and C-level endorsement. From the perspective of this value-based mindset, we’ve examined various project-related factors, such as the available technology and toolsets, software development methodologies, and the composition of our project teams.

Web 2.0 technologies, such as SOA, RIA, and so on, are finally delivering the software development cost and time benefits that we’ve been seeking for years. BSG makes extensive use of Web 2.0 technologies to enhance our projects, and we’re taking it a step further by developing an on-demand application framework to facilitate even more rapid technology deployment.

We’re firm believers in the Agile development paradigm. In our experience, Agile development leads to more engaged user communities, faster delivery cycles, and shorter user adoption curves. [Ed. note: see my interview with Don Dodge for more comments on using the Agile process to reduce project failures.]

Successfully deploying technology in complex environments can best be accomplished using smaller, more experienced project teams working in very close proximity to the user community. We use a ‘special forces’ approach to contain project cost and risk; this is superior to the highly people-intensive model often used in traditional consulting delivery models.

2. Are your projects really more successful than those performed by other consulting companies?

Our approach is tailored to the business problems we’re trying to solve. BSG works with organizations looking to renew themselves into next generation enterprises; success in their most important business initiatives is often highly dependent on the technology we are building with them. It’s these cases, where the technology and business stakes are both so high, which forced us to deeply consider the implications of our delivery model.

Consulting models that contain heavy project management controls do help limit risk, but they can also slow delivery and prove more costly. On the other hand, projects that don’t carefully adhere to a solid delivery methodology can quickly veer off course. We balance the elements of control and delivery speed to reduce risk while remaining responsive to our customers’ requirements.

The rhythm of our delivery process (shorter, more intense cycles, with deep customer involvement) produces a noticeable uptick in the emotional investment of the combined BSG-customer team. Our approach definitely erodes the ‘us vs. them’ mentality, which is so prevalent in many consulting arrangements. This ‘blended team’ method correlates very strongly with project success.

Clearly, some consulting organizations are successful using traditional approaches. However, having personally worked for large, conventional IT services companies, and seeing the results we’ve achieved to date at BSG, our model is clearly superior and produces better results for our customers.

3. Is this strictly a function of better project management, or are you doing something substantively different than everyone else?

Great project management is a non-negotiable ingredient, and we employ some of the best in the business. It’s critical for keeping projects on track, managing scope, and perhaps most importantly, managing the expectations and communications among the various project stakeholders. Our success to date results from a combination of the elements I mentioned before: delivering a business solution via BSG Concours, making full use of Web 2.0 technologies, adhering to the Agile approach, and bringing highly-experienced delivery teams to our projects.

We’ve also developed organizational self-awareness, which has helped us understand the importance of using smaller teams with more frequent deliverable ‘chunks’. The implication of this for billable hours and contract negotiations is significant.

Over the long-term, our on-demand Software as a Service (SaaS) application framework, which is currently under development, differentiates us substantively from the competition. This framework will enable BSG to deploy technology more rapidly and much more cost effectively than would be possible using traditional IT delivery models. SaaS applications reduce the implementation and infrastructure issues that are often associated with enterprise software deployment; our customers love that.

4. Why don’t more consulting companies follow this model?

Without a doubt, our approach will become more prevalent for companies trying to solve similar problems. We’re not the first company to advocate Agile development, but delivery models will adjust as more companies increasingly deploy Web 2.0 technologies.

Many of the global system integration (SI) companies are focused on different technology problems than ours. BPO or ERP implementations, for example, are better addressed by using large development teams located offshore in labor arbitrage markets. Although these consulting organizations have workable models for their focus, I question whether they can easily adapt to matters of complexity and innovation.

5. Your projects tend to be smaller, shorter, and more controlled than the larger software implementation efforts out there. In your private moments, do you sometimes hanker after these huge, money-churning engagements?

Of course we don’t walk away from large projects. However, we deliver those projects in smaller, shorter, and more controlled chunks than other companies!

[Thanks to Susan Scrupski for arranging this interview.]

July 8th, 2007

INTERVIEW: Don Dodge (Microsoft) on Avoiding Project Failure

Posted by Michael Krigsman @ 3:16 pm

Categories: Interview, Red Herring East 2007

Tags: Software, Project, Microsoft Corp., Don Dodge, Software Project, Michael Krigsman

Don Dodge has been around the software industry for a long time. Currently Director of Business Development, Emerging Business Team, at Microsoft, Don works closely with startups and venture capitalists. I’m an avid reader of Don’s blog (called the Next Big Thing), so it was with pleasure that I ran into him at the recent Red Herring East 2007 conference in Boston.

I asked Don a few questions about avoiding project failures, based on his experience working with many IT companies and products. If you want to understand the dynamics of project failure and success, I urge you to read Don’s comments carefully; He’s distilled lots of wisdom into a few short answers.

Don, when we met at the Red Herring conference, you said (and I’m paraphrasing here) that one of the major causes of failure is ‘unrealistic customers who expect a lot but are only willing to pay a little.’ Is it really that dangerous to be a tough negotiator?

Not unrealistic customers…unrealistic or vague project requirements.

In my experience, many software projects fail because the requirements were unclear right from the start, and buy-in was not achieved among all the various stakeholders who should have been involved. I’ve never seen a project get smaller…they always expand and get bigger. Second, most software projects are not “rip and replace”; they need to integrate with many other existing systems, which are often not managed or controlled by the project sponsor. Integrating with those other systems causes lots of delays and potentially huge architecture issues. Third, I think the biggest mistake in software projects is not doing regular progress checks and demos of code early and often. I worked at one company that used the “Extreme Programming” model, sometimes referred to as “Agile Process”. The great thing about Extreme Programming is that you must demo your work to the customer every three weeks. You can’t get too far off track if you are demoing to the customer every three weeks and getting them to approve the work.

Regarding your second question, I wouldn’t call it tough negotiating…just clear negotiating. Be very clear about the project specs, schedule, and success criteria. Then regularly check progress throughout the project.

You work with many startups and small companies in your role at Microsoft, and they’re often in an extremely weak negotiating position when dealing with enterprise buyers. Is there a way for these companies to command a price that lets them do a good job for demanding clients?

Startups are not in a weak negotiating position. They can move faster, have lower overhead, and offer a more personal approach than big companies. In fact, startups can charge lower prices and still make lots of money because they don’t have the huge overhead expense. The problem is that startups often feel like they’re in a weak position and therefore under-price themselves. In fact, however, they are not in a weak position.

At the same time, some projects are just not worth taking. If the requirements aren’t clear, if the schedule is unrealistic, or the price is too low…don’t take it. Life is too short.

Any time there’s a bidding war among vendors, common sense suggests that the buyer better have a clear idea of key project requirements — must-have features and critical performance criteria vs. less-essential stuff. Do you see this happening in actual practice?

Bidding wars often result in the “winner” losing money in the end.

If a customer bases his or her decision strictly on price, there are sure to be bad feelings somewhere down the line. Most people are honest and try to do a good job. However, mistakes happen when people move too quickly, without clearly documented requirements, without taking the time to map out a realistic schedule, and so on. A quick deadline for proposals or vendor selection can cause the customer to make mistakes.

What about the role of consulting partners in an under-funded project? How can the consultants manage customer expectations so the project doesn’t fail?

Big projects can get very complex…too complex for any one person to fully understand. Customers and project managers rationalize away issues, hoping to make up the shortfall downstream, perhaps cutting features or requirements in the desire to make it all fit together and work. That’s a recipe for disaster.

Projects that are “under-funded” or where customer expectations are not clear are in deep trouble. It gets back to the basic points I made in the first question:

• Be clear about requirements and get ALL customer stakeholders to agree
• Get the integration plan and architecture clear up front
• Demo your work early and often and get the customer to approve

Is there a special Microsoft methodology that helps avoid doomed projects? Or are you guys in the same boat as everyone else?

Microsoft has been building massive software projects for over 30 years. Microsoft projects rarely fail, but Windows Vista is a recent example of a major project schedule slip. The project was successful, but significantly behind schedule.

We spend lots of time getting requirements clearly documented, and bringing all the participant groups together, so everyone knows what they need to do and when. Successful software projects always have a strong leadership team that communicates clearly.

The mechanics of a successful project are pretty basic…but often overlooked.