Tag » IT

Guest blogger on Project Management – Part 2

Guest Blogger – Rick Wyatt

This is the second part of an 8-part series which looks at how IT and Business Leaders and Stakeholders can avoid common project pitfalls.

Be careful what you ask for!

You’ve probably seen the cartoon circulating over the years that illustrates the importance of requirements in delivering what’s needed.  It’s about a tree swing and the disparate interpretations of the deliverable when requirements are misunderstood.  Just search the Internet for “requirements cartoon” and you’ll find several versions.

It’s good for a chuckle, but the sad part is that it’s absolutely true!  The single most important piece of any project is requirements – clear, documented, validated, approved, understood and executed.  Here’s how to avoid requirements pitfalls in your projects:

  • Clear – Be specific and don’t assume people will just intuitively know what the customer needs.  If requirements are not spelled out in basic terms, they will be misunderstood.  As much as possible, requirements should be written to transfer the mental images and meaning from the mind of the customer to the reader’s mind.   This is not the time to show off vocabulary or writing style – keep it simple, crisp, to the point, descriptive and non-artistic.  Diagrams and screen shots are extremely helpful in conveying the desired information, but stop short of designing the solution – that comes later.
  • Documented – An artifact is needed that can be shared with your customer and the team, one that can be referred to repeatedly during the project lifecycle and that can be retained for audit purposes.  It doesn’t matter so much what format it’s in, so long as the format captures the specifics of the customer’s need.  There are lots of templates out there to choose from – Use Case, Business Requirements Document, etc.  Pick one that covers all the aspects of capturing the customer’s need and that can effectively convey that need to the team, then use it consistently in all your projects.
  • Validated – Once the requirements have been clearly documented, circle back with the customer to validate that what has been captured is complete and correct.  This reality check is essential to make sure nothing was missed and to edit the document where needed to clear up any fuzzy terms or concepts so that the customer’s need is clearly stated.
  • Approved – After validation, formal approval of the requirements document by the customer is needed with the understanding that the validated and approved requirements define what is in scope (and not in scope), they provide a definition of project success and they are now frozen.  This will provide a control for managing project scope and preventing scope creep.  Any subsequent changes to requirements should require formal approval by the project Sponsor and could impact project duration and cost.
  • Understood – Requirements define the customer’s need (the “What”) and the project team uses them as the basis to create the solution design (the “How”) that will meet that need.  To be successful in this process, it’s essential that requirements are completely understood by the project team.  The best way to ensure complete understanding is to conduct a Requirements Review meeting for the customer and the team to jointly walk through the document, discuss each requirement in detail and get all questions answered.  At the end of the session, everyone should have the same understanding of what is needed.
  • Executed – Requirements drive all subsequent activities in the project.  Technical Specifications and Design combine requirements with technology to form the solution.  The Test Plan and Test Cases are created to confirm the solution works as intended and all requirements are met.  User Acceptance Testing (UAT) provides the customer an opportunity to confirm what they asked for has been correctly and completely delivered.  In the end, each requirement should be traceable through the entire project life cycle to ensure all have been appropriately addressed in design, development, testing and deployment.

The time spent up front in the project process on requirements will have a huge return on that investment when you successfully breeze through UAT and deploy your project.  On the other hand, skimp on requirements and you could find yourself bogged down in rework, or worse.  It truly pays to be careful what you ask for!

Copyright 2010, Rick Wyatt, IPT Concepts, LLC

Emerging Technology – Friend or Foe?

Deciding when to adopt an emerging technology within your business is a critical decision. This post poses a few key questions to consider.

Emerging TechnologiesDeciding when to adopt an emerging technology within your business is a critical decision.  Not every business is the same when it comes to emerging technologies. You may be working for an innovative, growth-oriented company that’s always on the lookout for new solutions, or you could have responsibility for an established, structured organization that’s wary of jumping into the latest IT invention.  Either way, if you’re going to stay competitive in today’s marketplace, you’ve got to keep your eye on emerging technologies and know how best to benefit from them.

The question is: how do I know when to embrace an emerging technology? The bad news is that there is no “silver bullet” that provides the answer to this question.  The good news is that there are a few critical questions that can help you decide.

  • Is technology a competitive differentiator for your company? if so, emerging technology is your friend.  You should budget and resource to investigate emerging technologies when they are on the “bleeding edge”.
  • How aggressive is your business strategy? If your company has aggressive growth plans that involve innovations, then emerging technology is your friend.  Many emerging technologies can help your organization grow with less initial investment.  Even if the technologies don’t work for the long-term, they may let you be first to market with a new product or service.
  • Does your company have a highly structured culture and approach to initiatives? if so, then emerging technology may be your foe.  By their nature emerging technologies are often fraught with starts and stops with projects rarely going as planned.
  • Do your company processes include R&D activities? If not, then emerging technology may be your foe.  Companies without a tolerance for R&D activities will lose patience with emerging technologies.
  • Is 100% quality at all times a priority for your company? If so, then emerging technologies may be your foe.  You will be better served to wait until a technology is mature before adoption.
  • Do your clients demand innovative solutions? If so, emerging technology is your friend.  By embracing new technologies earlier in their lifecycle you can meet your client demands sooner than the competition.

Assessing your company’s culture and processes will allow you to determine whether emerging technologies are right for your enterprise.  Be sure to readdress the tolerance for emerging technologies frequently since company strategies change frequently.  Whether a friend or foe, emerging technologies will play a big part in your IT success.

Guest Blogger on Project Management

Guest Blogger – Rick Wyatt

This is the first part of an 8-part series which looks at how IT and Business Leaders and Stakeholders can avoid common project pitfalls.

The first date you hear is not “the date”

How many times have you been in meetings where the Business has asked IT to deliver a project of some sort and the question is casually posed to IT, “So, when do you think you can get this done?”  At that point, the best thing you could do would be to plug your ears and not hear their answer.  Why?  Because anything they say at that point in a project lifecycle is just an unqualified best guess.  But what happens time after time is the whole room hears IT say they think they might be able to deliver the project by around a certain date, and from that moment forward, everyone thinks that’s “the date”, and nothing could be further from the truth.

Let’s look at the reality of this situation.  At conception, a project is simply an idea – pure vapor.  Here are some of the components of project initiation and planning that will need to be fleshed out to move that idea from vapor to reality:

  • Documented, detailed requirements.  Everyone, the Sponsor, project team and the project stakeholders, need to understand and agree upon what is to be delivered.  This establishes the scope and drives the understanding and creation of the tasks needed to turn vapor into a tangible, expected outcome.  Until this is done, we don’t know what we’re being asked to deliver, so how can we provide more than a ball-park estimate for delivery?
  • Priority.  How important is this piece of work?  On one hand, if this is the most important thing to company profit or growth, it might need at the top of the project list and take precedence over all other discretionary work.  On the other hand, if it’s a nice-to-have item, it might be low on the list and would need to compete for resources with the other less critical projects.  At one end of the spectrum, the project could have a dedicated team and executive help clearing roadblocks, and at the other end, the project could be delayed by higher priority projects that consume the resources and cause your project work to be sporadic.
  • Capacity.  How much discretionary work can IT successfully take on?  What skill sets are needed for your project tasks and when will those resources be available?  You can create a beautiful project plan with all the tasks and dependencies well thought out and documented, but until you have a good understanding of the specific resource that will perform each of those tasks and when they’ll be available to do so, how can expected task completion dates be determined?  And don’t forget the biggest capacity planning pitfall – production support.  Unless you have the ability to dedicate resources 100% to the project, you run the risk of losing some of their time to unplanned “lights-on” activities such as resolving production problems.  This can be difficult to avoid in relatively lean IT shops and equally difficult to manage for project planning purposes.
  • Buy versus build.  Do you have the skills internally to deliver the requirements or will you need to rent some expertise from contractors?  Do you have the capacity to do the work yourself or will you need to outsource some of all of the work because your internal resource won’t be available to meet time requirements?  Do you have a hard stop date and need to do “right-to-left planning” to meet your date but internal capacity is inadequate for the job?  Is there an off-the-shelf solution available that would be more cost effective, less risky or faster to market?  All of these unknowns need to be considered and decisions made in order to begin to understand the project timeline.
  • Risk.  Is this new technology with high risk associated to it because “you don’t know what you don’t know”, or has your team done this a ton of times before, it’s a core competency and it’s low risk?  Is the complexity of the project relatively high with multiple opportunities for time consuming issues to arise, or is it straight forward and easy?  Generally, time estimates for high risk projects are themselves more risky than the lower risk projects which can more accurately be estimated.
  • Project Plan.  The typical waterfall project lifecycle moves through seven basic phases:  Initiation, Requirements, Design, Development, Testing, Deployment and Close.  The first six, Initiation through Deployment, comprise the delivery estimate.  In the Initiation phase, all you have is a concept with no tasks to hang on it that would lead to delivery of the desired outcome.  Until you document the requirements (the “what”), you don’t really know what you’re delivering.  Until you create the design (the “how”), you have no real idea how the requirements will be met.  And there’s no way to understand the development and testing efforts until you’ve gone through the requirements and design process so you know what to code and test.  But here’s the kicker – tasks on a project plan, by best practice and common sense, need to be identified and estimated by the people who will actually be doing the work – not the Subject Matter Experts or the Managers who tend to underestimate based on how long it would take for them to do it (not their lower level resource with emerging skills) or tend to be optimistic in their estimates due to pressure from above or a desire to please.

All of this gives credence to the basic premise at the beginning of this article:  The first date you hear is not “the date”.   OK, let’s assume that’s a given.  But we can’t wait until delivery of the project is imminent to communicate to the Sponsor and stakeholders when they can expect to receive their deliverables, so here’s what we can do.

As we move through the project lifecycle, more and more becomes known about all of the items discussed above, and as our knowledge in these areas increases, the accuracy of our estimates also increases.  That’s why the more mature IT shops and their business stakeholders adopt a model of increasing estimate accuracy based on project phases.  At the completion of each phase, the components of project estimates are reviewed and updated so that estimates can be refined and restated to reflect what we’ve learned to that point.

A model used by some IT organizations is as follows:

At Completion  of Project Phase:

Accuracy of Estimates:


+100% or -50%


+50% or -25%


+25% or -10%


+10% or -5%


Using this model in an example, let’s say we have a project that involves developing a new accounting system.  When IT reviews the concept and provides their experience estimate based solely on a high level understanding of what might be involved, the estimates at that point are accurate to a range of +100% or -50%.  Let’s say their estimate at project initiation calls for the project to take 12 months to deliver.  What this is actually telling you is the true delivery effort will take somewhere between a high of 24 months down to a low of 6 months, twice as long or half as long as their best guess at that point.  Not quite the first date you heard!  As the project progresses and unknowns become known, the team re-estimates at the end of each phase with an ever reducing range of accuracy, as indicated in the model.

What are the impacts if IT and Business Leaders and Stakeholders ignore the reality of estimate accuracy described above?  This is what their project experiences could look like:

  • IT rarely delivers projects “on time”, defined as in keeping with their initial high level estimate which is just a guess.
  • Confidence in IT project capabilities suffers due to their track record of never delivering “on time”.
  • Project teams are constantly under pressure to reduce timelines so they can deliver “on time”, resulting in too much overtime, too much distraction and stress, burn-out for key resources and turnover.
  • In order to get delivery closer to the fictional “on time” date, projects can wind up with quality issues since testing is the last phase in the project lifecycle and is the usual target for cutting time to meet dates.  This leads to higher project costs due to rework.

The next article will focus on project requirements and their importance to over-all project success.

Copyright 2009, Rick Wyatt, IPT Concepts, LLC

‘Tis the season for planning

While we are enjoying the holidays our businesses must continue.  How well your business finishes 2009 and starts 2010 is dependent upon good planning.  Although plans without action are not very useful, actions without plans can be very harmful.  Below are five tips for planning success.

  1. Set aside dedicated planning time.  It is easy for planning to be “rescheduled” due to immediate priorities.  Everyone has urgent items that keep taking precedence over planning and strategic thinking.  During the holidays is a great time to focus on planning.  Be sure to set aside a day or half-day to plan for 2010.
  2. Define clear objectives for planning.  A good plan does not get created by accident.  You need an approach to make the plan come alive.  Create an agenda for your planning session.  Even if you are the only one doing the planning, know what your objectives are for the plan and attack them.  Whether you will be growing your business through acquisition, expansion, or new products and services, all of your activities need clear objectives and measures of success.  Be sure you have objectives for your planning as well and consider all areas of your business: sales and marketing, infrastructure, product development, support services, customer care, company leadership, your competitors, etc.  Whether you need to make major changes, protect the base, or create a market, a stable plan with clear objectives is essential.
  3. Invite advisors – but not friends.  Friends are great and can be very supportive.  They are a necessary part of any successful business, but you need your trusted advisors to participate in planning.  You need advisors who will challenge you and push you to excel.  They should help you identify your blindspots and assist in identifying ways to drive the business forward.  Stay focused during the planning and make the best use of the talent available to you.  Be open to new ideas, prioritize the ideas to be implemented, and then send your advisors away.  Now you need some “alone time” with your leadership team.
  4. Turn strategies into Tactics.  A plan is only as good as your ability to execute it.  Take the strategies you’ve identified and determine how they will be implemented.  Answer questions like: How much will this cost?; How soon will I get a return on my investment?; Can I afford to do this now — can I afford not to?; What other resources do I need?  Once you have each strategy defined, go back and be sure you have a holistic plan that includes the “baseline” efforts you perform today as well as any new activities.  This will ensure you have an integrated plan that can succeed.
  5. GO!  Be strategic at least a few minutes each day.  Things don’t change overnight, but without effort, they never change.  Spend a few minutes every day making sure you are sticking with your plans.  Don’t be afraid to abandon something if it isn’t working out, just do so consciously and not because you didn’t have time to think about it.  Measure your progress and hold yourself accountable for the successful implementation of the strategies.

If you spend the time now to create a good plan for 2010, you will reap the rewards.  You will be more confident in your business model and everyone on your team will know where the company is headed.  They will have a plan to rally around, and they will help it succeed.

Enjoy the holidays and have a great 2010!