Great Product Features Have Solid Business Case

For our company, great features rarely come from high-octane project brainstorming sessions where the heavens open to reveal the glory of God.  Instead, they come from lowly customers here on earth.

Here’s how it happens:

A customer calls up and says, “Why is your product so lame?  Why doesn’t it do such-and-such?”

“That’s none of your business!” cries an eavesdropping passerby.

Oops, no.  Not the correct response.  Instead I ask, “How would you like it to work?”

Nine times out of ten that question turns into a great new feature.  We discuss the business case and work out an alteration that fits the common usage much better.  Customer is happy; we’re happy.  Now we just need to sell it to the executive management and development team.
Why is this exchange so valuable?  Because it comes from an actual customer with little vested interest in the product.  They just want it to work better so they can get their work done faster.

BINGO!!!

That’s the key.  Anytime you can reduce admin time or improve product usage, everyone wins.  Nobody likes a hard product.  Dreaming up great new features in a boardroom rarely accomplishes those basic goals.  Talking to customers is where it comes from.

Problem is, who’s talking to customers?  Tech support, sales, and maybe a marketing hopeful willing to mingle with the great unwashed.  These are the lowlife employees nobody listens to.  So how does the customer need get filtered up the channel to executives and then back down to the development team?

Give them a database.  Let them submit feedback from the trenches.  If they can articulate the business need clearly and effectively, people will listen.  The best features always come from customers.

Project Tasks and Issues Tracking

You identify the scope and nature of a project. Design the project plan and assign resources and begin the process of real work and plan executions. Many tasks follow a predicted path and glide down the slope toward completion. Others hit speed bumps and issues arise. If you only encounter a few issues along the way, they are fairly easy to manage with emails and spreadsheets. The issues still require special attention and follow up costing time and energy, but manageable. What happens if you 130 issues arise in a short period of time (as is often the case in software development and bug fixes)? Spreadsheets and emails won’t cut it. In no time you lose track of events, issues and milestones. I am pointing out the obvious. But I have counseled hundreds of project managers using outdated tools and methods to track issues. Maybe project management and issue tracking software/tools cost a little money (others cost a lot of money), but believe me, they will pay for themselves many times over in saved projects, efficiency and ultimately the bottom line.

U.S. Losing Competitive Edge in Technology

The recent eWeek story regarding U.S. decline in science and technology (see below) is nothing new.  We’ve heard this same story for twenty years.  But is anyone listening?

http://www.eweek.com/c/a/IT-Infrastructure/US-Losing-Competitive-Edge-in-Technology-Science-National-Science-Board-610257/

Over the Christmas break, I did my bit to encourage passion in software development, engineering, and project management.  I mentored a college student with an Arduio board.  (See http://www.arduino.cc/)  The Arduino is a microcontroller with inputs and outputs for controlling external devices.  It’s big in university engineering departments.  Awesome, dude!

We stayed up past midnight wiring circuits and slinging C++ code to exercise the Arduino I/O ports.  In a rat’s nest of wires, LED’s flashed, speakers squealed, and relays clattered.  Cool!  When it was over, the kid had a new passion for product development and engineering principles.

Code ‘til you drop, and then do it again tomorrow!  That’s my answer to declining technology in the U.S.  And I suppose it’s also my preferred project management style.

Groupthink…Project Killer

Susan Cain just wrote a piece in the NY Times talking about the destructive force of groupthink (article found here: http://www.nytimes.com/2012/01/15/opinion/sunday/the-rise-of-the-new-groupthink.html?pagewanted=all). This started me thinking how groupthink applies to project management and the synergy created or hampered within a project team.
After reading the article I am more convinced that as a project manager it is important to encourage and draw out people’s experience and opinions. It is imperative that project teams have a voice and strong leadership to maintain project goals while remaining open to the team voices. Otherwise, we have the inverse problem. Instead of shortsighted groupthink that has little innovation and a blind rudder. You get analysis paralysis where the goal is clear but the wheels just spin. Which is worse? Probably about the same…nothing gets done, or it does, but it is completely wrong and misses the mark. What do you think?

Earned Value Increases As It Travels

Earned value (or the value you receive on your intellectual property) increases as it travels through the supply chain.  In other words, the farther an item travels from the manufacturer to the consumer, the more value it brings the manufacturer.  Consumer items change hands many times before they end up in consumer’s hands.  Each time they change hands, more money is invested, and therefore the value goes up.

Consider the illustration below.  A single egg isn’t worth much until it is developed.  Its value rises 100 times from nest to table.

Have you ever considered that software does the same thing?  It earns value as it passes from idea to developer, to QA, to packaging, to reseller, and finally to consumer.  So, the true Earned Value of a product is dependent upon its position in the supply chain, not just at the coder’s keyboard.  You account for such value by quantifying your products on their route to the consumer.

Negotiating and Managing Project Expectations

One of the many factors in project cost overruns is due to setting unreasonable expectations. Whether working as a consultant outside a company or as a project manager within a company, all too often we become “yes” men to secure a deal or please superiors. We may win in the short term by getting the job or by delaying management’s wrath by telling them what they want to hear, but, in the long run, both scenarios are losers. As a consultant you land the gig and wind up with bad word of mouth advertising as being late and over budget. As an internal project manager you develop a reputation of being unreliable and/or overly optimistic. Instead, be real and upfront about duration and costs of expected projects. Give pushback to help set reasonable expectations. Maybe someone else will promise the moon? You should challenge competitors’ unreasonable assertions. You may still wind up losing the deal, but in the long run you will maintain your reputation and eventually land more deals because of it. Short term pain for long term gain is tough in this economy. What is your word worth and where do you go to get your reputation back?

Do you like Project Robots?

You just buried your mom and returned from the funeral. You’re a Project Manager on a high profile project for one of the largest tech companies in the world.  It has only been one day since the funeral and you are still raw with emotion.  Now imagine that you get an email informing you that you are not getting a break from the loss of your mom, but in fact, your workload has been increased.  How about a spouse fighting cancer?  Need a little time?  No!  Instead, how about an increased workload?  Sound crazy? Well, imagine no more…these are true stories.  This brings me to an important point.
In talking with a friend of mine with 26+ years of project management experience about Agile vs. Waterfall methods, he said, “You can have all the methods and processes you want but it all comes down to personal relationships and human intervention”.  This gentleman was responsible for one of the largest SAP installations in US history. I was taken aback by the simple answer when he stated another simple cliché, “Take care of your team and your team will take care of you”, which means that they will take care of the project.
The examples given in the beginning of this blog are not meant to say that we shouldn’t be tough or suck it up.  However, besides being in my opinion morally wrong, it is flat bad for business.  Is the man whom just buried his wife still ready to climb that mountain for the team?  Or, is he waiting for the first chance to jump ship?
All too often we pay lip service to our employees, “Let me know if you need any more resources”, while completely ignoring the realities of life.
I guess the bottom line is we can keep on pushing the machine, but what happens when the machine navigator gets ran over?  Does the machine keep going and if so, who is driving…a robot?
Make sure when you ask someone if they need help that you don’t ignore the reality that is staring you right in the face — unless you like robots.

7 Things You Need to Know About Development Project Estimations

Whether you are a project manager planning for a smooth implementation of a plan or a project sponsor on whose decisions a project depends, you cannot escape from the fact that project estimation is essential to its success. In the first place, there are three basic requirements that a project must satisfy: schedule, budget, and quality. The need to work within these essential project boundaries poses a huge challenge to everyone in the central management team.

There are various aspects that affect project estimates, such as team skills and experience levels, available technology, use of full-time or part-time resources, project quality management, risks, iteration, development environment, requirements, and most of all, the level of commitment of all project members.

Moreover, project estimations do not need to be too complicated. There are tools, methodologies, and best practices that can help project management teams, from sponsors to project managers, agree on estimates and push development efforts forward. Some of these include the following:

  1. Project estimates must be based on the application’s architecture. Making estimates based on an application’s architecture should give you a clear idea of the length of the entire development project phase. Moreover, an architecture-based estimation provides you a macro-level view of the resources needed to complete the project.
  2. Project estimations should also come from the ground up. All estimates must add up, and estimating the collective efforts of the production teams that work on the application’s modules helps identify the number of in-house and outsourced consultants that you need to hire for the entire project, as well as have a clear idea of the collective man-hours required to code modules or finish all features of the application. Ground-up estimates are provided by project team members and do not necessarily match top-level estimates exactly. In this case, it is best to add a percentage of architecture-based estimates to give room to possible reworks, risks, and other events that may or may not be within the control of the project staff.
  3. Do not forget modular estimates. Once you have a clear idea of the architecture, it becomes easier to identify the modules that make up the entirety of the application. Knowing the nature of these modules should help you identify which can be done in-house or onshore, or by an offshore development team. Moreover, given the location and team composition of each development team that works on a module, it becomes easier to identify the technical and financial resources needed to work on the codes.
  4. Development language matters. Whether the development language is Java, .Net, C++ or any other popular language used by software engineers, team that will be hired for the project must be knowledgeable in it. Some development efforts require higher skills in these languages, while some only need basic functional knowledge, and the levels of specialization in any of these languages have corresponding rates. Most of the time, the chosen development language depends on the chosen platform, and certain platforms run on specialized hardware.
  5. You cannot promise upper management dramatic costs from offshoring. While there are greater savings from having development work done by offshore teams composed of workers whose rates are significantly lower from onshore staff, you must consider communication, knowledge transfer, technical set-up, and software installation costs in your financial estimates. Estimating costs is often more about managing expectations, but as the project matures, it should be clearer whether the money spent on it was money that was spent well.
  6. Project estimation software and tools help identify “what-if” scenarios. Over the years, project managers have devised ways to automate project schedule, framework, cost, and staffing estimates. Some estimation applications also have sample historical data or models based on real-world examples. If your business has a lot in common with the samples in the estimation tool, it can help you identify what-if scenarios and in turn include risks, buffers, and iteration estimates.
  7. Price break-down helps in prioritization. Breaking down the total cost of the project helps management decide which parts of a system should be prioritized, delayed, or even cancel. Estimating costs for a new project may not be easy, but project sponsors and managers must be able to know and agree on the breakdown of costs of development, technical requirements, and overhead.

By ExecutiveBrief -online resource on process management, project management, and process improvement.

Success Factors in Knowledge Management

Knowledge management professionals must keep in mind that KM’s explicit end-goal is profitability while its implicit purpose is to empower participants through intellectual platforms and processes that promote learning and practical knowledge.

Knowledge, without a doubt, plays an important role in the success of any organization. In fact, in order to maintain a competitive advantage, modern organizations incorporate knowledge creation, knowledge sharing, and knowledge management into their business processes. The mere survival of many organizations hinges on the strength of their capabilities; moreover, companies form decisions based on their relevant knowledge of their business landscapes.

Thanks to developments in information and communication technologies, it is now easier to develop, store, and transfer knowledge. This capability is particularly true among organizations with global workforces. After all, international competition and globalization are the driving forces behind most technological innovations, and companies quickly take advantage of these developments when it comes to managing the creation and flow of information.

“Ultimately, leveraging relevant knowledge assets to improve organizational performance is what knowledge management is all about,” says Murray E. Jennex in his book, Knowledge Management in Modern Organizations (2007). However, in spite of the lightning-speed creation of new knowledge and the improvements in communication technologies, many organizations still find that their knowledge management practices are lacking. Specifically, within client-consultant relationships, knowledge transfer does not always translate into better performance by all project team members, nor does it always translate into the successful delivery of projects.

To be successful, knowledge management programs require more than simply conducting training sessions or transferring knowledge. Practitioners must always remember that KM’s explicit end-goal is profitability – while KM’s implicit purpose is to empower participants by providing them with the intellectual platforms and processes that promote learning and practical knowledge.

Here are a few factors that contribute to successful knowledge management initiatives:

  • Linkage between knowledge and economic performance – Knowledge management exists because it enables the organization to reach its business goals. Otherwise, there is no point in putting together all the best practices, tacit knowledge, and skill sets in a cohesive system that is accessible by all parties – when and where they need it. As business increasingly becomes more global, the competition for greater market share depends on the capabilities of its players to a certain degree. KM practitioners must be able to identify the business value of knowledge management in their organizations – whether it is to manage projects, provide back-office operations services or to give ideas on how processes can be better optimized – among others. In most consulting relationships, knowledge is the currency by which all transactions are made.
  • Setting and communicating clear objectives for specific organizational or project levels – Heather Kreech, the Director of Knowledge Communications of the International Institute for Sustainable Development has some specific ideas on this very subject. In her paper, Success Factors in Knowledge Management (2005), she states that knowledge-sharing works best when knowledge managers “gather and communicate knowledge at the project/activity/field level before [they] begin to aggregate up to corporate systems and general knowledge marketing strategies”. Having a specific organizational level or project group in mind, results in better designed knowledge management systems, training programs, and tools that can meet the specific needs of workers.
  • Having the appropriate systems and infrastructure – Ideally, knowledge is created, processed, stored, and archived. Managing the process of creating knowledge, communicating this knowledge to participants, and making knowledge available to anyone in the organization, means that an organization must have the right communication systems and data storage facilities. However, it is not enough to simply store knowledge as this knowledge must be found whenever it is needed. Thus, the availability of internal search facilities and computer-based training programs is critical.
  • Having the right champions – KM initiatives need project and process champions who can rally the support of everyone – from top management down to individual staff members. Having management support can result in the freeing up of resources – such as financial, expertise, and infrastructure – all of which are critical to the successful implementation of KM projects. Financial backing means that KM managers can implement training programs, hire both internal and external specialists – as well as acquire the required infrastructure to manage training programs. On the other hand, access to experts from either within or outside the organization, means better identification of knowledge gaps and training requirements, and more importantly, engineering training and communication programs that meet the said needs.

By ExecutiveBrief
Technology Management Resource for Business Leaders
http://www.executivebrief.com
¼/p>