Shipulski On Design

When choosing projects there are two competing questions: Is it big enough? And, is it small enough? The project must be big enough to generate the profits required by the company’s growth objectives.  Larger growth objectives require larger projects.  Yet the project has to be small enough to be completed within the time constraints defined by the growth objectives.  Tighter time constraints require smaller projects.

When the projected revenue generated by the candidate project is less than what’s needed to meet the growth objectives, the project is deemed “not big enough.”  But what if the candidate project is the largest project that the project team can imagine? Does that say something about the project team’s imagination or the growth objectives?  Open question: How do tell the difference between a project that is too small to meet the growth objectives and growth objectives that demand projects larger than the project team’s imagination?

When the projected launch date of the candidate project is later than the date of first revenue defined in the growth plan, the project plan is deemed “too long.”  The team is then asked to sharpen their pencils and return with a launch date that meets the revenue timeline.  And when the revised schedule also violates the revenue timeline, the project is deemed “too big.” Open question: How do you tell the difference between a project that is too big to meet the revenue timeline and a revenue timeline that is too stringent to allow a project of sufficient size?

Theoretically, there are candidate projects that are big enough to meet the growth objectives and small enough that their launch dates meet revenue timelines.  But in practice, candidate projects are either too small to meet growth objectives or too large to meet revenue timelines.  And, yes, I have seen candidate projects that are both too small and too large.  But this says more about the growth objectives, revenue timelines, and the number of projects that run concurrently (too few resources spread over too many projects).

Growth objectives are good, and so are projects that fit with the team’s capabilities to deliver.  Incremental revenue that comes sooner rather than later is good.  And so are project timelines that are governed by the work content, resources applied to the projects, and good product development practices.

Truth is, we need it all – projects that deliver the sizzle that sells and projects that launch sooner rather than later.  And year-on-year, we need to get better at delivering on all of it.  And the best way I know to do all that is to ritualistically invest in the people that do the work and the tools they use.

“Horse Yin and Yang” by onecog2many is licensed under CC BY 2.0.

Comments are closed.