Showing posts with label managing up. Show all posts
Showing posts with label managing up. Show all posts

Thursday, March 15, 2007

Intrapreneurship: Entrepreneurship within your big company

We all know what Entrepreneurship is: creating new businesses from whole cloth, feeding a need in the marketplace and figuring out how to make a buck in the process.

What if you are an employee within a large company with an idea to revolutionize a portion of your business by creating a new product or service that is outside your company's portfolio of products and services? Furthermore, this idea might be outside the typical kind of business you do. Could you convince your superiors to see the value in your ideas? Could you get them to support the development of your ideas? Could you get funding, resources and time? Could you add real value to the bottom line of your company?

This is what I call Intrapreneurship -- Entrepreneurship within an existing company. Intrapreneurship is at least as hard as it's counterpart, and fails at least as often. However, it is essential to the success of the organization. Talented executives understand and foster environments that balance the necessary tasks of getting traditional work done with innovation and new business development.

Regrettably it is too common for the brass at the helm of the office to be up to their knees in tactical issues and keeping customer satisfaction high to focus on ideas that are evolutionary or revolutionary. Due to these constraints it is not possible to affect real change just by coming up with an idea and dropping it in the "suggestion box" or whatever the equivalent of that is for you.

It is therefore left to the individual contributor to develop as much of the project as can be done as a grass-roots effort before sending the project up the chain and actively selling the project to parties that might be positively effected by your idea. Find partners and advocates at any level within any group of the organization to help you develop your ideas. Two people from different functional areas making the argument for the resources to run the same project carries a lot of weight. Three is even better.

You must actively sell your idea. Develop training material, presentations and business cases, and be prepared to stop in the hallway and deliver a pitch to anyone willing to listen. Eventually (and this is, in my experience, a multi-year process) either the project will be explicitly adopted or rejected. Either way, you did your best.

Whenever I complete this process one way or the other I feel fulfilled. It is satisfying that your idea, thought up, developed, worked on and perhaps even built by you was considered carefully. Even if the idea is rejected, you know that important stakeholders and decision makers have thought about what you have to say (sometimes because you bugged them until they did). If you have done your research and pulled together a consortium of individuals to work on your project, frequently when it is not part of their regular job, you will be remembered as an effective innovator. Subsequent projects will become easier to propose, both because of the new relationships and because of the additional experience.

And eventually you'll hit a real winner. And that is when the real work begins.

Saturday, March 3, 2007

Software project management "cliff's notes" found

This week I was given an opportunity. My boss's boss asked me to be the "project champion" for a set of features that we (the company) would like to see in our application, but that nobody has time to actually do.

I recognize this as both an opportunity and a potential pitfall. It is an opportunity because this may allow me to gain enough influence to fundamentally alter some of the brain damage we've been inflicting on ourselves for the last few years.

This is a potential pitfall because it is just as likely that this is an empty label given to a sucker who is complaining to shut him up. With the label comes extra responsibility but no authority and failure ensues.

To explore the issue, and figure out what it means to be a project "champion" at my company, I decided to write a proposal. It might be a bit of a power play to massage my job function, maybe get a budget of my own and start hacking away at the afore mentioned brain damage, but at a minimum the process of thinking about what the heck would solve this problem.

Anyway, this is just a really long way of saying that I did a Google search for "project champion" and found notes from a course on software project management by the University of Glamorgan in the UK. Many of the principles there will be old-hat to anyone involved in software projects, but there are good sections on development methodology, planning and some of the corporate-political aspects of project management.