Nikola Tesla - The Forgotten Wizard

Resource leveling in a project..a useful task or a pain in the ass

The past few days have been extremely frustrating as I am trying to fix and plan my resources in a 400+ task with numerous swim wires connecting them. Managing resources in MS project is not a simple task. You can put in the names but when it comes to leveling them to the respective capacities, you have to go through a lot of pain and trust me the tool which MS project provides for auto leveling messes up the project big time..so should we put effort in leveling resources in detail? considering most project plans are never followed as they are made. What I believe is that we should do resource leveling!! but not in depth to the lowest detail. A more high level for the core team should be good enough so that the PM is aware of the challenges he/she might face in executing the phases. The rest should be left when the task is about to be started. Its as simple as following the thumb rule..." don't cross the bridge until you have reached it..but do figure out where the bridges are"

Setting up a project networking site

Updating stakeholders or team members on the status of a project is an important task for a PM. I have seen numerous PMs adding a recurring task in there project plan (MS project of course) on sending weekly emails or reports to the relevant team members. Thinking of this, the age we are living in is of collaboration, with every hooked to Facebook, Twitter and other networking sites. So why don't we have a collaboration/networking/wiki for our projects? Their are numerous tools on the Internet like wordpress or Google Sites that let you set up collaboration sites in a Giffy by which team members can keep track on anouncements, project calendar, events and other goofy things that are happening.

A New Business Strategy: Give Up the Core

One of the reason I find this article very interesting is that it applies to a lot of local IT divisions who are constantly cramped by looking after technology and other operational issues, and in the mist of all this they forget and loose customer focus. I am not suggesting that you give up every operational activity you perform but be smart in what you need to do.

In making outsourcing decisions, companies are very careful to hold onto the core--those activities and competences that are at the heart of the business. The core represents its very being; it tells its employees and customers what it does.

That's why Sprint's plans to outsource the management of its cellular network is unusual. In the mobile phone industry, letting go of the network is akin to cutting out the heart of the company. But according to an article in Monday's Wall Street Journal, the company is in talks with Ericsson to hand over the maintenance of its cell towers and transfer thousands of employees to the equipment vendor. The deal would cut Sprint's costs by about 20%, according to the Journal. And it would free resources for product innovation and the development of partnerships, as the company seeks new sources of revenue growth.

But when it starts to give up core competencies, what will Sprint be? The answer will become less clear over time but, ironically, Sprint is finally onto something that companies in emerging markets have jumped onto already.

In my research into how companies are fighting commoditization and shrinking markets, I spent some time with Bharti Airtel, a fast-growing telecom network based in India. (VG Narayanan and Asis Martinez of HBS worked with me on this research). Way back in 2003, CEO Sunil Mittal signed away the operation of the firm's telecommunications network to Ericsson, Siemens, and Nokia, in the belief that they could better solve the problem of meeting mounting demand, leaving him to focus on solving customer issues. The move was shocking at the time, and represented a philosophical shift--from protecting the core to solving customer problems, without regard to company boundaries. From a bunker mentality to a kind of near-agnosticism. It's the ultimate step toward becoming customer-centric, adopting a mindset that begins with the customer and then moves to the particulars of who will deliver the right products or services.

So what exactly is Bharti now? Previously, Bharti knew for certain what it was and what it did, with management of the network an essential component to its being. Now, it's the sum total of its on-going arrangements, a shape-shifting enterprise that slips into market crevices. It's far less certain what it is, but it's been rewarded with both revenues and market share.

Such agnosticism isn't limited to the mobile phone industry. Apple, for instance, relies on many other companies to produce and accessorize its phenomenally successful products. Shortly after the iPhone was launched on June 29, 2007, a third party ― iSuppli Corp. ― took the phone apart and found that a large portion of the innards of the device were made by third-party companies such as German semiconductor supplier Infineon, Epson, and Samsung. Five percent of the accessories available in Apple stores are made by Apple, and the goal is to bring it to zero. At Cisco, employees are expected to embrace a "no-technology-religion," meaning that they are agnostic about platforms and standards and will consider supporting any technology endeavor that meets customer needs.

Being agnostic or customer-centric does not mean blindly following customers' instructions. Customers themselves may not be able to articulate their needs precisely. Instead, it involves a creative process driven by a deep and holistic understanding of the problems that the organization's customers are facing, together with a careful consideration of the capabilities both inside and outside the organization needed to solve those problems. The goal isn't to push your offerings onto customer, but to immerse yourself in customers' problems to offer up unique solutions. To make it, you need to be willing to give up some of your being and live with a little nothingness.

Why IT Solutions Are Never Simple

via Susan Cramm by Susan Cramm on 4/1/09

Without concerted effort, what was once neat and tidy becomes marred and messy. Just finding something in the garage feels like an archaeological expedition. Periodically, when someone dies, or relocates, or becomes disgusted, there's a whirlwind of activity to purge and reorganize. This cathartic experience is followed by a brief period of exhilaration, until time passes and entropy exerts itself once again.

So of course the airlines didn't intend to build "multiple old computer systems that don't share information well." When these systems were initially constructed (in the 60s and 70s), they were neat and tidy. Application requirements were defined from the point of view of a department and the needs of the people within it. The approach to programming reflected a simple and static world where it was the norm to embed data and business rules together with the logic necessary to support a business function — for example, to book and manage reservations. No one conceived that customers would book their own travel, that airlines would merge and spin off, that competing airlines would sell seats through code share agreements, or that competition would become so fierce as to necessitate greeting them by name and remembering their favorite drink.

To respond to these demands in a timely manner, IT did what we all do. They packed as much as they could in the existing "application" garages. When it became impossible to enter them without breaking something, they built new ones to store additional, but redundant, data, business rules, and logic. In an attempt to coordinate these applications to support business processes, they built a myriad of point-to-point interfaces between the applications. As a result of these seemingly efficient but short-sighted approaches, the systems architecture of the average 20+ year company looks something like this (aptly named, the "scare" diagram):

Because of this complexity, many companies don't have a definitive understanding of their customers, products, and performance and have difficulty modifying business processes in response to new opportunities and competitive realities. Furthermore, they devote the lion's share of their IT spend to maintaining existing systems rather than innovating new capabilities.

This isn't new news, of course. During the 1990's, we started to realize that IT systems often inhibited rather than enabled change. Since then, IT and business leaders have been working hard to increase agility by replacing systems and using new approaches to promote integration and commonality. Along the way, we have learned that:

1. Across-the-board "scrape and rebuild" of systems usually doesn't make sense because often the gain isn't worth the pain. This approach is like knocking down your garage and throwing out everything in it. There's a lot of good stuff in your existing applications and there is no guarantee that the new systems will be that much better, less complex, or cheaper than the old ones.
2. Hiding existing systems complexity using a "layer and leave" approach makes it easier to use and integrate existing systems, but doesn't reduce the costs of supporting inflexible and redundant systems. This approach is like hiring a garage "concierge" to find things and put them away. Unfortunately, you have to pay for the concierge service as well as the costs of maintaining the garages.
3. The best way to manage complexity is to "clean as you go". This is a combination of the two approaches — implemented on a project-by-project basis. Each project is defined in a way that moves the enterprise closer to the desired "to be" architecture. Using our garage analogy, to move something in, one or two things must be reorganized or moved out. This approach includes layering, but also extracting critical data and functionality out from applications and rebuilding them so that they can be managed as an enterprise asset.

"Things alter for the worse spontaneously, if they be not altered for the better designedly." To be altered for the better requires that everyone agree on what "better" is. "Better" for the enterprise over the long term is often at odds with short-term business goals and profitability. The "clean as you go" approach will always entail additional time, effort, and resources.

IT isn't alone in the need to simplify. As Rosabeth Moss Kanter pointed out, "Companies sow the seeds of their own decline in adding too many things — product variations, business units, independent subsidiaries — without integrating them." Keep in mind that, since IT architectures mirror the inherent complexity of the businesses that they support, it's impossible to have a truly agile and cost-effective technical architecture without simplified business architecture.

It's hard to say "no" to the extra product line, merger, reporting package or, for that matter, bicycle. Simplicity's just not that simple. How are you doing getting there?