Subscribe via RSS Feed

Tag: "project success"

Prototype Technologies are Ruining Your Prototypes

Prototyping-TechnologiesI want to challenge our thinking on how we use prototype technology in our world of software development. Are we using prototypes to help our business users all get on the same page and visualize a solution?  Or are prototypes targeted at our internal team, so they can understand what the resulting system “should look and behave like”?

Prototyping can mean different things to different groups. For purposes of this post, let’s use this definition:

A prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or learned from.

When I researched this definition, there were some key points that consistently turned up.  They include:

  • A Prototype isn’t the final product.It is designed to test a vision and illustrate a requirement for a final product. For example, if you want to design a car with the gear shift on the left side of the driving wheel, you could create a prototype with only that level of detail. It may not have a horn etc… Just enough to ‘prototype’ the proposed change.
  • A Prototype is used to eliminate ambiguity. In other words, it helps drive a common vision across project participants.  For example:  “Oh… so when you said make it smaller, you really meant tiny or minuscule. I see now”.
  • A Prototype is used to drive feedback. This helps an idea grow before making huge resource or financial commitments.  We might build a working prototype of an Internet Alarm Clock that plays your music stored in the Cloud on the Internet.  It may be fully functioning, but it is a one-off. Its purpose is to gather our initial reactions and generate additional ideas based on the working prototype.
  • Finally, a Prototype might be a Proof-of-Concept. This is used to test the feasibility of an idea and whether the initial vision can actually be delivered with the desired results. This is more of a design based prototype.

Why We Prototype

To summarize, prototypes can be used to:

  • Drive a common vision across stakeholders
  • Confirm our understanding of a desired end-state
  • Provide a forum for feedback among internal stakeholders and external customers.
  • Act as a proof of concept, flushing out the feasibility of an idea

Most prototypes serve one or more of the above the purposes.

These days, there are many tools for prototyping.  Everything from HTML for creating  working-light-weight prototypes for review to wireframe tools such as iRise or Balsamiq.  There are even PowerPoint files with “wireframe templates” in them to build wireframes and mockups using PowerPoint and it’s native tools.

So What’s the Problem?

In spite of the great tools out there, I’ve been in situations where these tools actually get in the way of our goals. They don’t help the business users get to alignment. In fact, prototypes created with these tools can actually drive a “compromise” in their design. Let me explain using an example:

I have three business users working to define a new “quick order” system for their web site.  The Business Analysts spend a couple of hours working with them to collect their vision for the new shopping experience and all the tweaks necessary to take their website to the next level.

We take these requirements and have a designer build a quick prototype so we can make sure this is what they wanted. The final wireframes (built in HTML or another technology) are then emailed around to the business folks for feedback.

Now Volleyball Sets In!

Volleyball starts when one group, in this case the designers, emails information to the users and then the users email back their clarification or changes and the cycle continues.

It’s like each side is sending something over the wall or volleyball net. And, just like in volleyball, if one side drops the ball (or gives up) the other side scores a point.

At this point, the  challenge  is to effectively create a  common vision across multiple stakeholders using email! (Hmmm, I wonder if this is how congress works.)

More often than not, the business gets the prototype to where it’s “Good Enough” and then approves it. They want to get going and hope they can tweak it as it is being developed.

Let’s see how effective this is at achieving our goals for prototyping:

  • Drive a common vision
  • Confirm understanding of a need
  • Provide a forum for feedback
  • Checking feasibility

I would argue that this process is extremely ineffective and delivers inconsistent results.  When someone says this is close enough, are they really saying they feel like we are all on the same page?

If it DID accomplish these goals, then any system that used this approach would have less change requests, less defects and lower overall development cost.

But there is a better way. The Lo-Fi way.

Enter Lo-Fi Prototypes

Here is another way to create and finalize prototypes.  Let’s go back to the meeting where the Business Analysts were collecting requirements.  After they collected the high-level requirements, they use actual post-its that are cut into screen widgets. For example, there are post-its in the shape of data entry fields, list boxes etc. You can even use fan-folded post-its looking like a drop down box.

Now we ask the business users to actually build their screens. Using the post-its, scissors and markers, they create a lo-fidelity prototype. Whenever possible, we print out existing screens, even screens of a competitor, and mark these up with post-its and markers.

The prototype is NOT designed to flush out usability or the end look and  feel. It is used only to enable the business users, as a group, to quickly build their lo-fidelity prototypes and share their vision and intent for the system.

I’ll emphasize that it is CRITICAL they understand that the final system will be a bit different due to design requirements, usability, branding, etc…

This approach is extremely effective and scalable. In fact, I have facilitated a small group of business users using this method to create more than 50 screens and report prototypes in a session.

There are a couple of great benefits using this approach:

  • The stakeholders feel ownership for the prototypes
  • It eliminates ambiguity, frustration and misunderstandings due to volleyball
  • Stakeholders can iterate immediately
  • They work as a group, helping drive alignment which results in less rework
  • Prototypes can be scanned into the requirement documents

At times, we give a few of the more critical lo-fi prototypes to a developer to create a hi-fi prototype (an HTML based prototype that can be interactive) over lunch.  And yes – I said over lunch! The users can then get a real understanding (feedback) on their vision.

So if you really want to use prototypes effectively, forget about all those fancy tools. This down-to-earth, friendly  approach will help you fast path collecting clear requirements and reduce confusion around the real needs and intent of a system, eliminating the pain of volleyball.

As a final note, I believe there is a place for using technology in prototyping. I am a fan of those tools. But I think we have gotten so technology focused, we tend to forget the real goal and use the technology appropriately.

What kind of prototyping tools does your team use? How do you think the post-it approach would go over in your environment?

June 7, 2011 | 2 comments | View Post

The Biggest Management Lie You’ll Ever Hear: “I Won’t Hold You To It”

Wont-Hold-You-To-ItI have to be honest on this one.  Not only have I been on the receiving end of this, but I am guilty of saying these words as well:

“I need a high-level estimate.  I won’t hold you to it. I know you typically need more time to create an estimate, but I am looking for an order-of-magnitude estimate. Can you get me something by tomorrow? Again, I won’t hold you to it. I know you need to do a full estimation process to give me the real number. I’m just looking for a swag.”

And then, at some point  in the future, management gets the  real estimate. It is almost always higher (sometimes double) and management (myself included) can’t understand how it got that way.   How can you go from $100k to $125 or $150k?   Or from two months to almost four months?

And, inevitably,  the creator of the swag estimate is asked,  “So what would it take to get down to the original estimate?”

So What is Management Really Thinking?

When you are the recipient of the line: “I won’t hold you to it”, the  first question you have to ask yourself is:  What was management thinking?  When management asks us to provide a high-level estimate, what do they really need that number for? It seems they were saying, don’t worry about being inaccurate or way off … I won’t hold it against you! But this isn’t rational.

Management is Trying to Make a Business Decision!

They are going to use that number for decisions. Decisions at their level! Decisions that may determine:

  • Go/no-go on a project, or
  • Do I need to plan for more budget and if so, what kind of dollars are we thinking of, or
  • Do I need to request more staffing or can I give away resources, etc.

These are typically higher-level decisions.  That means the estimates they are asking for are actually as important as any other combination of estimates we provide.

The next question: Does Management really mean it when they say “We won’t hold you to it”?

The truth is, they will hold you accountable for the number they receive.  No one in leadership is going to say: Pull a number out of the air, and wink-wink, we know it’s way off. But no worries, I know you threw a dart at a board of numbers and just gave me the result squared.

What they are really saying is that they need an estimate without going through the typical rigor of process that may take days or weeks.  I am not looking for a plan with milestones and staffing requirements.  I am looking for an overall high-level plan without that detail information. So don’t try and cover yourself on this. I won’t create pain for you.  Just give me the high-level estimate.

They may not understand, that getting them the high-level estimate requires us to build the details.  Only then will the high-level numbers have enough validity so they can make business decisions based on them.

A Best Practice: Communicate Your Concerns! Call Them Out on It

The next time management says I need an estimate but I won’t hold you to it, call them out on it! Ask them what they need the estimate for and what decisions will it be used for.  Are they looking to free up resources?  Are they putting in a budget request? Ask how painful it will be if the estimate is off by x%?   Odds are they may pad the estimate (their budgets) for planning purposes.

Start having a conversation so you can truly help management as best you can, and as a partner.

One thing is for sure, if they are asking you for an estimate, they are using it for business reasons. And, bottom line, you will be the owner of that estimate!

Estimating is a Minefield!

Estimating can be a minefield. Everyone asks for estimates. We ask a child how long a chore will take, or when they’ll be home from a party. We ask a boss when our review will be done.  Marketing has been asking me when will I have this blog article complete? (By the way, they clearly tell me they will hold me to it!)

We need a consistent language around estimating and more importantly, we need consistent expectations around how we estimate and what we “can” and what we “can’t” estimate, repeatedly and predictably.

So the next few articles are going to focus on common obstacles that cause a team estimate to either be order-of-magnitudes incorrect or simply an estimate that does not command everyone’s confidence.

We’ll start next post with about padding estimates and why we should NEVER do it.  I will present you a better alternative.

So, how many times has management asked you for an estimate that you won’t be held to?

Photo Credit: Denise Chan

March 2, 2011 | 1 comment | View Post

Quality Assurance: Band-Aid Fix or Vaccine Cure to Software Projects

The Vaccine Approach to a Software Development Project: Quality Assurance as a Value Added Partner

Syringe-1Last week, I talked about the risks that go hand-in-hand with the Bandaid approach to software quality assurance.  With the vaccine approach, software quality assurance is not seen as overhead or a bottleneck. Instead, it is a value added partner that brings transparency and visibility in software development predictability.

Significantly different than the Band-Aid approach, in the vaccine approach the software quality assurance team is dedicated, full-time participants within software development teams.  They are co-located and work collaboratively with both the business and developers.  Acceptance criteria is defined in collaboration with the business and integrated with requirements.  This provides significant advantage over the “Band-Aid” approach to testing, both within projects and across the enterprise application portfolio.

The Vaccine approach to software quality assurance provides more than operational benefits. It strengthens both the delivery team and the quality assurance function overall.  Being embedded with and dedicated to a development team, software quality assurance people are immersed in the business problem as well as the solution while it is being developed.  Being fluent in the application, a tester is more likely to recognize the difference between an application failure and an environmental or situational blocker, and better prepared to correct the situation.  As a result, they are less likely to raise false defect reports that create “noise” that masks the state of application quality and impairs team efficiency by wasting other people’s time in disposition.

This approach also protects quality assurance leaders.  When able to work only part-time in any given project, software quality assurance can do little more than produce testing artifacts and perform tactical execution. Working in full collaboration with a project development team, however, allows the software quality assurance team to gain deep business knowledge.  A quality assurance team that is immersed in the problem domain is in good position to be IT knowledge workers.  This makes them better business problem solvers, and stronger participants in IT solution delivery overall.

Engaged Participant vs. Disengaged Auditor

The intended deliverable of any IT project is a technically sound, functionally fit business solution.  This is achieved through the engaged participation of all IT disciplines, including infrastructure, requirement, development, and quality assurance.  By only playing the role of auditor, the quality assurance team is a disengaged member of the solution team that certifies an application as production-ready.  Alternatively, by collaborating from the early stages of the software development lifecycle, and executing quality assurance continuously throughout, the software quality assurance team works as a value-added partner that directly contributes to an increased understanding and gradual evolution of a business solution.  Ultimately, this approach increases both the value of software quality assurance and the return on IT investments.

What steps can your team take to move from a bandaid approach to a more holistic approach to software quality assurance and testing?

Photo Credit: Andres Rueda

December 28, 2010 | 0 comments | View Post

Quality Assurance: Band-Aid Fix or Vaccine Cure to Software Projects

If Quality Assurance is intended to be a vaccine to projects, then why is it so often being used as a Band-Aid?

BandAid-1In our daily life, we take preventative measures such as flu vaccines early in a season to avoid, eliminate, and/or to reduce chances to get sick. This is similar to QA being part of a software development project early on in order to reduce defects and minimize project duration and cost. Unlike a conventional testing approach–which merely reacts to whatever has been designed or developed and frequently is perceived as interfering with development)–QA’s role early in the Software Development Cycle helps improve predictability and makes development faster, and less aggravating.

During my career, I have seen QA teams that are “shared resources” supporting many projects simultaneously rather than dedicated to specific projects.  Huge armies of QA teams execute defined test cases/scripts to test and certify an application once development is complete.  Because QA team members lack application familiarity and test only at the end of the development lifecycle, they require significant execution support. Often, the feedback they provide is late in coming and often inaccurate.

The Value of the Vaccine Approach

Compare this to a vaccine approach where the QA team is dedicated for the duration of the software development project and testers are co-located with the business and development team.  Because they collaborate with the development team on formulating acceptance criteria and engage in testing continuously through development, they can spot the commonly-overlooked showstopper problem. Now, QA feedback is considered as timely and relevant and a value added partner in delivery. This increases the efficiency of the software development process and the effectiveness of solutions produced.

We all have our examples of exciting projects turned into nightmares. Creeping deadlines, tsunamis of defects, applications that fail to deploy or performance bottlenecks that just cannot be found. Unfortunately, these kinds of situations always occur at times when they are least welcome – right before the project deadline, during the holiday season or when you had planned that nice weekend getaway. Most of these nightmares can be eliminated if QA is considered a vaccine for the project lifecycle rather than a Band-Aid fix.

The Risks of the Band-Aid Approach

There are many operational risks with Band-Aid approach.  It assumes that the test cases are of high quality, and that feedback is timely and actionable.  These are unwarranted assumptions.  Like any IT artifact, test cases may be ambiguous or confusing to testers (of poor technical construction) or they don’t test what needs to be tested (of poor functional construction). Since QA leads are shared across several applications, there are chances for error in writing test cases.  Being part-time on every project, the QA team is forced to work independently from the development team.  Test cases/scripts are often written to abstract specifications in the early stages, before software is ready to be tested, and executed in much later stages of a project once development is complete.  They are not written in conjunction with the development of the software, or in full collaboration with development.  Also, the development team is often not made aware of specific QA and UAT acceptance criteria, nor does it receive testing feedback, until very late stages of a project.

There is financial risk as well.  This approach emphasizes unit-cost efficiency of test execution over a holistic approach to quality assurance.  On a test-cases-that-can-be-executed-per-person basis this model looks attractive, but to be cost-effective, there must be low overhead of execution.  The greater the effort required to stage testing activity (e.g., with test data or instructions to carryout testing), or to interpret the results of testing performed, the greater cost of execution.

What approach does your IT organization have to QA?

Next week, I will take a closer look at the benefits of a more holistic, Vaccine approach to QA and testing.

Photo Credit: Guerrilla Futures | Jason Tester

December 13, 2010 | 1 comment | View Post

Everything I Know About Software Development I Learned from Elephants

The Swiss Army Knife of the Animal Kingdom

Elephant-2Last week, I talked about the importance of introducing the elephants in the room.  So now that we have the elephant in the room, let’s examine it and see what we can learn from elephant behavior and how we can apply it to software development. The irony of the “elephant in the room” metaphor is that it suggests that elephants are these large, bulky creatures that are imposing and not dynamic. In fact, elephants are one of the most versatile mammals on this planet. The elephant’s trunk is used to tear up food, so the elephant can digest it. It is a hand that can grasp objects, a means of drinking without having to bend over, and a way of  spraying mud on themselves to protect their skin from the sun. It is even used as a tool for  social interactions, to enhance their highly developed sense of smell, and to defend themselves from predators.

To deliver software predictably, we need to become dynamic, adaptable creatures as well. As the speed of technology gets faster and faster, we’re going to have to give up the idea of just doing one or two things really, really well. We’ll have to be like the elephants’ trunk. We have to know the foundation of coding, but not be married to any single language. We’ll need to understand the best practices of project management, but be flexible in our methodology and apply the best methodology to the best practice. We will need to master requirements facilitation, but have many different tools to gather requirements and to custom fit the requirements process to the appropriate projects.

 

Even We Can Become Extinct

If we are rigid and only do things one way, technology will pass us by and we’ll become extinct. However, if we are adaptable with our tools, practices, and methodologies, we’ll continue to evolve to meet the demands of business using the best that current technology has to offer.

In the past, the slower speed of technology may have meant that a method and tool would be useful for many years. In the fast pace of technology today, it is never the case that we can say that any idea, method, or tool works every time. We need to be constantly transforming ourselves, our ideas, methods and  tools to confront new challenges.

We may come to find more and more that projects are changed or canceled once we have gained momentum. Perhaps what made business sense when we started the project no longer makes sense due to new technology which has changed the marketplace. Rather than letting this disturb our equilibrium, we should begin to develop habits that allow us to shift rapidly and be adaptable to such change. Those in technology who can rapidly adapt will excel in tomorrow’s marketplace.

Being flexible and adaptable isn’t easy. It requires us to constantly let go of things that we know as true. Something may have worked for us before, but it may not work now. Or perhaps we have a perfect tool in mind for the job, but our client has a tool they like more. We have to let go of what has worked in the past for what it will take to accomplish the challenge before us.

 

And Maybe Dumbo Wasn’t That Far Off Base

One last thing we can learn from elephants is to use our big ears. Disney’s portrayal of Dumbo, the elephant with ears big as wings, wasn’t that far off base: Elephants have huge ears and an exceptional power of hearing.

As a predictable partner, we also need to always be using our ears. Not just to listen to what our clients are saying, but to really understand the meaning of what they are saying.

We can do this by maintaining a curiosity with our clients and what unique strengths and issues they have. Listening is a good first step, but when we are curious about our clients’ strengths and issues, then we have motivation to not just hear, but to understand.

Also, using our ears helps ensure that we are speaking the same language. It ensures that we are talking apples to apples and oranges to oranges. Our active listening helps our clients to know that they are being heard.

So next time you pop in the Disney classic about the elephant with the big ears, take note. Just like the underdog elephant who learned to fly, we can also use our ears to help us find success  with our teams and clients.

December 6, 2010 | 0 comments | View Post

Do you have an opinion on why some software projects fail to deliver?

Survey Says!

If you have an opinion on why some software projects fail to deliver, then you’re invited to participate in our online survey.

Take just 5 minutes  and we’ll send you a $5 Amazon gift card (details on the survey site)!

Start now: http://www.surveymonkey.com/s/geneca-mytwocents

September 30, 2010 | 0 comments | View Post

Beyond Complete: Success is Making a Lasting Positive Impact

What is “success” to you? Imagine yourself working on a project. The project is on-time and on-budget. All of the requirements have been met. But, how successful have you been with the project? Have you made a lasting impact with your customers? Are they eager to work with you on the next project? Are they recommending your work to others?

Reaching the Destination May Require an Unexpected Route

A customer engagement is not just about meeting the common standard measurements of success (on-time, on-budget, etc.), but is about partnering with your customers to predictably deliver what is needed for them to be successful in their business. It is about anticipating what the customer needs. It is about the courage to deliver a difficult message when you discover that the recommended solution is not going to deliver the desired results, even if you fear that you’ll be perceived as having made a mistake. And, it is about being flexible in your approach so you resolve issues instead of worrying about meeting a plan that you know is not working.

One of the most successful projects that I’ve worked on was neither “on-time” nor “on-budget” and the final delivered solution was significantly different than what was requested in the original requirements. Yet, the project was considered a success – the customer was extremely happy with the results and continued to engage with my company and team for additional work.

127385974_4c9b5e3acf_mFulfilling a True Need

What made this project successful?  Our team partnered with the customer to understand what the true needs of the project were. In the middle of the project, we determined that while we could deliver to the original commitments, the solution that the customer would have received would not have met the customer’s needs. Instead of continuing to deliver to the flawed plan, the team alerted the customer to the issues and worked with them to restructure the plan to deliver a solution that better met their needs.

Was the re-planning painful? Of course it was. As more information was uncovered, we actually restructured the project and the sub-teams twice during the project life cycle. So, in addition to keeping the client satisfied, there were also challenges in keeping the team focused and delivering quality. However, the end result was worth the pain in the middle of the project. The final solution delivered the value that the customer needed within the necessary time frame. The team was able to celebrate a successful delivery.

If we had stuck to the original plan, the team could have delivered the project on-time and on-budget. We would have met all the requirements of the project. It is even possible that we could have gotten future work from the customer. However, the customer’s perception of us would have been just another consulting company that they could use for work if needed.

Instead, by not delivering on-time or on-budget, but by predictably delivering value with “no surprises”, we became a trusted advisor to our customer and they became enthusiastic advocates of our company and our people.

What does “no surprises” mean to you? When have you changed the course resulting in a win for all?

Photo Credit: Olivier Bareau

July 20, 2010 | 0 comments | View Post
« Previous Page