Monday, July 23, 2012

Strategic & Business Planning: a Project Manager’s Role [Matt Glei]

When your company does “strategic” planning or yearly budget planning, do they come to you and want you to estimate the expense budget, the capital budget, the headcount and schedule for one or more projects in a single day?  How do you do this quickly and but still come up with estimates that you can live with?

The first thing to remember is that this comes up on a yearly cycle, so if they came to you last November, they’ll be back again this November.  Remembering this might give you a little notice and time to do your homework.  Set a reminder in your calendar that November is “planning month.”

Another important item is to know how much detail your company wants as part of this planning.  For example, a larger business unit might want rough estimates for many projects so they can add them up and extrapolate resource levels (expenses, capital, headcount, etc.) in general for the business and worry less about the detail of each project.  If this is their desire, your job is a bit easier since you want reasonable Scientific Wild-Ass Guesses (SWAGs) rather than fully detailed project plans.  However, the emphasis is on “Scientific,” not the WAG.
 
On the other hand, if the company is asking for schedules that they will use as benchmarks on the projects yet to be started or even fully-scoped, then the problem is much more challenging.  Think of this case as “Extreme Project Planning.”  To do this well requires a solid methodology and some focused time from the business unit.

One way to do a reasonable SWAG is as follows (with a small, experienced team):

• Write up a brief scope of each project, describing the key features and goals.  Identify a first pass on any known-risk items.

• Imagine the team work roles (number and type of individual) that will be needed and likely availability given present projects already in motion.  Put this in a spreadsheet for the next year (or whatever the horizon is) per role, with a percentage of each person’s role spent in each month.

• Add it up.  The sum with be the FTE engineers needed in each month.  You can multiply this by the average cost per FTE engineer month based on present actuals (total expense dollars spent this year / total FTE).  This is a useful number to keep on hand for ballpark planning.

• Now you have staffing needs and rough schedule (don’t forget to use a most-likely schedule rather than best-case and take into account realistic hiring or staffing timeframes).  For capital, you can best use examples from projects similar to the ones proposed – tooling, NRE, etc.

• I then put the scope from above and the derived schedules, staffing needs, capital, etc. onto a one-page pro-forma data sheet and make sure that it is submitted with the rest of the material.  It documents the logic used to make the estimate and mentions any key risks or assumptions.

Later, when everyone has a different opinion about what was committed to, this documentation can be very useful.  The project may change and be re-scoped, but this snapshot details what the basis of the estimate submitted was.  Make sure it is dated and time-stamped.  Mark it confidential.  Review it with your marketing product manager or other key stakeholders.

For the Extreme Project Planning case, the SWAG steps outlined above still work, but you must also really dig into more detail on project goals, product features as well as staffing and technical risks.  Otherwise you will be held accountable without having done the due diligence needed.  You seldom have time to do a detailed project plan with WBS and complete PERT analysis.  Having good metrics from similar projects can help a lot, but only if they are comparable to the proposed project.

I found that the SWAG method could be used for planning multiple projects over multiple years, and then be updated as each budget cycle approached or the actual project start neared.  By then you often know more about the features, goals and risks, so an update and more detailed planning is appropriate.

At Hewlett Packard, beginning in the 1980s, they instituted a 10-step business planning process that allocated time throughout the year to do the homework (data gathering, analysis and so forth) in small discrete steps rather than take a month off at the most critical time of year to do all the work (often poorly).

Please comment with other or better approaches, especially for "Extreme Project Planning.".  There’s always a better way!

____________________________________________________________________
Matt Glei is a contributing blogger to the ProjectConnections' blog.  ProjectConnections is a corporate sponsor of the Engineering Leadership SIG.  This entry was reposted with the permission of Matt Glei.

Matt is also owner of Know-how Consulting in Honolulu, Hawaii.  This consultancy provides performance coaching in areas such as collaboration, knowledge management, intellectual property, virtual teams, program, project and risk management.

Matt also has long experience in product development, project portfolios and strategic planning. Matt has also developed several Quality Systems, compliant with ISO and FDA guidelines.

Matt is certified as a Project Management Professional by PMI and is a  Certified Scrum Master.

Matt has spent his 30-year career in high technology and medical product development and operations.  His background includes significant periods in Research & Development, Operations as well as Marketing.  His career includes 5-person start-ups, all the way to 350 M$ high-volume businesses with thousands of employees.  As different as these company situations appear, the fundamental performance problems remain the same.

Sunday, July 8, 2012

June Meeting Notes - Shampa Banerjee on Thinking Strategically – A Survival Skill for Today’s Technical Leaders [Ravi Ganesan]


Shampa Banerjee spoke on the topic: Thinking Strategically – A Survival Skill for Today’s Technical Lenders to Engineering Leadership SIG, SVForum on 21st June.

She began by saying “Let’s have a conversation” and asked about what challenged Technical Leaders the most in their work place. The audience homed in on the intrinsic tussle between Engineering and Sales. Sales made promises about new product features and got the commissions while Engineering took on the responsibility to deliver those promised features and toiled for long hours, every day.

Then, Shampa mentioned her experience as a technical leader in several companies, from startups to the big ones. Matrix Management upon acquisition by a bigger company brought in successive changes. The changes began showing results when Product Management was eventually made to report to the Technology VP. This led to engineers questioning what they were developing, rather than developing to requirements: “Would I use what I am developing?

She highlighted a current trend. More than CIO’s or CTO’s, it is Sales and Marketing, who are introducing the use of relevant Social Networking tools in their companies. What then, is the role of Technical Leaders in a rapidly evolving landscape? How do they position themselves in the company’s business strategy of selling their products, services to customers?

The audience began to enunciate various scenarios that challenged them, adding what changes were needed to produce the desired results. Here are some instances shared by the audience:

  • Technology leader took control of the product roadmap. As a result, prioritizing and scheduling engineering effort to match promises made to customers became relatively easy.
  • In a Professional Services Group, the Account Manager and the Technical Expert were competent possessing excellent leadership skills. One of them was made a leader, though both were accountable for success. Their collaborative efforts brought success. As the business expanded, each was paired with a junior from the other side to facilitate succession. Ensuring the sharing of responsibility for success between the two functions was very instrumental in instilling collaboration.
  • In a medical devices company, it was necessary to get the Specifications Writer and the Specification Requirements Consumer to be synchronized. One Product Manager was assigned for every 10 engineers. Audience was polled for what might be a good ratio. The consensus was that independent of the ratio, Product Management and Engineering needed a tight collaboration, in tight alignment, for product success.
  • Writing requirements requires (pun unintended) the specification of requirements without mentioning implementation or solution. In a particular company, Product Management and the Development leader collaborated in analyzing the initial list of requirements and rewriting them independent of implementation. The list shrank to one third the initial size making it easier for Development to scope effort and timelines.
  • Even in some organizations that use iterative, rapid processes, a Business Analyst negotiates between Engineering and Customers. The success hinges solely in how well collaboration is ensured by executive management.
The audience resoundingly favored the need for Product Management to work closely with engineers. Challenges are the scale of work and time zone.

Shampa displayed a high level approximation of the traditional model of an Engineering Team as a two dimensional matrix based on skill sets. The horizontal axis denotes Technical Capabilities while the vertical axis denotes Process Orientation.
1.       Top Right Quadrant: Functions of VP, Engineering
2.       Bottom Right Quadrant: CTO, Chief Architect
3.       Top Left Quadrant: Program Managers
4.       Bottom Left Quadrant: Customers? (drew audience laughter)
Questions were raised about this model:
  • Where is innovation?
  • Where is business acumen?
The Audience commented that the above two should also be added as additional dimensions to the above model in today’s competitive market.
Shampa chimed in that Technology leaders need to be aware of this as they are not only responsible for the success of their technology but also for the success of the business. The Technology leader can provide inputs to the business and needs to be part of business decisions. Technology leaders need to be a partner with Sales and work together on decisions that impact engineering effort.
Success of a company is not just Technology. What else is required? Shampa presented a slide that compared “Where we are” and “Where we should be”.
These were presented as two adjacent lists, as follows:

WE ARE HERE                                                                    WE SHOULD BE HERE
Technology as a strategy                                            Business strategy (offer technology options)
Participate in Sales                                                     Partner with Sales (educate as required)
Partnership Discussions (due diligence stage)              Co-drive Partnership Decisions (take a stake)
Influence Product Roadmap                                       Co-Own the Product Roadmap
Fund Raising (not the driver)                                      Fund Raising: Lead  vs  tech discussions only
Build vs Buy Decisions                                               Build vs Buy: Help define business priorities

An example was provided of a large manufacturing company that asked for 15 different things. Engineering empowered Sales to negotiate with the customer. This resulted in 5 requirements only.

The Audience now offered their experience in how the two sides can engage the customer.
·         Have 2 lists: Can-Do and Cannot-Do maintained by Engineering and shared with Sales.
·         Engineering collaboration with Sales and vice versa can be ensured with suitable incentive structures that hold both responsible for success. The typical model of Sales being paid a commission upon Contract Signing and Engineering paid full time to deliver much later is rife with opportunity for misaligned goals.
·         Product Management, as a representative of Engineering, accompanies Sales to size up promised features. Before a deal is signed, the Product Manager needs to have a say. Externally customer facing and internally working closely with engineering the product manager is the liaison, a conduit to ensure that what is promised can be delivered (in scope, time and with allocated resources).
·         Startups don’t have the luxury of affording Product Managers. The CEO plays the role of Product Management. Sometimes, this role may not be the right fit. Executive training (retraining too) is recommended in such situations, as is done in larger and more mature companies.
·         Engineering Technology Leaders need to be honest and be vocal with Executive Management.
·         What can be done to pre-empt failures? Share everything with the people early-on. Schedule periodic meetings to track concerns and address issues quickly. Decisions are logged. If the road hasn’t changed the decision stays.
·         A comment made from a User Experience testing group drew laughter: Avoid listening only to the hippo (to the highest paid person). Ask if we are doing the hippo thing now.

Shampa summarized the audience feedback above  as follows: that outcomes really depend on personalities. Often a failure is due to the people and not due to the technology / technical solution. As an example, while the CEO decides what needs to be done, she recommends that a Technology Executive be part of the Executive Fundraising Team rather than just computing the cost, number of development hires, and delivery timelines.

What are the essential ingredients of a Technology Leader?
  • Need to be a great Communicator: not only in verbal and written skills but also in Body Language
  • Need to be approachable. If the leader is seemingly distant, people will be afraid to ask, discuss and share
  • Need to redefine / reframe the problem. Albert Einstein said: “You cannot solve a problem from the same consciousness that created it. You must learn to see the world anew”.
  • Need to be a community builder
  • Need to have an eye to anticipate (every one today is a visionary and can be)
It is paramount in current times for a Technology Leader to be an all-rounder; with 360 degree skills to be approached and accepted.

Kennedy said: “Some men (person) see things as they are and ask “why?”. I dream of things that never were and ask “why not?” The new technology leader rephrases “Biz is Business” with “Passion is Business”. This person needs to be in tune with breaking news, to retrain, to accept change by expanding and adapting oneself. Collaboration is a necessity; i.e. work with a common goal where each owns up for success. Note that Operations as a big team (that we knew) is gone now. It is only a handful of people.

Shampa emphasized the need for New Company Structures and Incentives that can ensure collaboration and sharing of responsibility for success in the business. Examples:
  • Large companies can work as several small fleets and behave like startups.
  • Have open discussions: Should everyone have a share in the sales commission? Do we incentivize the right behavior? Abolish hierarchy?
  • The book “In search of Excellence” was mentioned. Even in large companies, smaller teams were given big incentives and allowed to use the resources of the large company. Eg. Skunkworks.
The Audience responded how a very large company in our area worked as a large number of small teams as if each one was a startup. Two years ago, they found this strategy was not working favorably.
Shampa concluded that big or small, companies need to revise incentives and control structure in order to ensure that
  • Customer facing Sales&Marketing and Producing folks in Engineering Work together
  • Both own delivery (i.e. a well-defined common success is identified)
_____________________________________________________________
Ravi Ganesan has over 20 years of experience in Product and Engineering Management. As General Manager of TIBCO India, he was responsible for all fiscal and operations planning. He hired dozens of engineers, coordinated with external organizations and set up processes and procedures for development, facilities, finance, IT, release, support, and travel. Similarly, as a Senior Director in Adapter Engineering, TIBCO he was responsible for product management and engineering execution for over 25 adapter product lines (about 15% of company revenue). He has proven himself to be highly effective at Program and Process Management. He was responsible for the day-to-day management of two off-shore contracting companies in India, with a total of close to 100 employees. Among the areas for which he was responsible: setting product requirements and specifications; on-time delivery; budget management; designing SLAs and performance metrics; and coordinating and communicating with other organizations (marketing, sales, alliance contracts, legal, release, etc.).