From Idea To Execution Denver University College Of Business 022310 - DP Harshman

From Idea to ExecutionWorking with IT

Presented by:

Donald P (DP) Harshman

To The:

Innovation Design & Execution Course

University of Denver – Daniels College Of BusinessInstructor:

Clinical Professor Paul M Bauer

Chair – Information Technology and Electronic Commerce

February 23, 2010

Anatomy of a Bright Idea …and what comes next

• Where does innovation come from?• “I find out what the world needs. Then I go ahead and invent it.”

– Thomas Edison 1

• However. Often, most often, the idea is the easy part:• “None of my inventions came by accident. I see a worthwhile

need to be met and I make trial after trial until it comes. What it boils down to is one percent inspiration and ninety-nine percent perspiration.” – Thomas Edison 1

• “Opportunity is missed by most people because it is dressed in overalls and looks like work. – Thomas Edison 1

• The same is true when working with IT• A great idea = a lot of hard work …

2From Idea to Execution ...

Assumptions for tonight’s discussion …

• Your bright idea is IT related or involves IT somehow

• You know your business processes and procedures

• You have an idea of how IT might be able to help … but:• You’ve never actually worked with IT before

• You are not a professional IT architect, system engineer, or “guru”

• You don’t know how to “sling code” (and aren’t at all interested)

• Thus, it is necessary to know something about IT before you can successfully work with and within IT


What IT is …

• IT is a group of administrators, engineers and technicians … dedicated to assisting business in taking advantage of the computer and internet revolutions• The revolution is ongoing and just getting started (you ain’t seen

nothin’ yet)

• IT is primarily data and information related• It is also business process related

• And management reporting related

• And physical hardware and communications related

• But it is primarily “data and information related”• That is IT’s “thing”


A Side-Bar on Information …

• It has been said: “Information is power.” • This is inaccurate

• Information, defined: “Knowledge derived from study experience or instruction” – American Heritage Dictionary (also wisdom)

• But that doesn’t give you power

• Information is not power, it is potential power … at best• In Physics, power is roughly defined as the rate at which work is

being accomplished over a period of time (watt, horsepower, …)

• In other words, power is energy being applied to something

• It is not a “loose” theoretical concept

• If you are not applying “it” you are not getting power


A Side-Bar on Information … (cont'd)

• Though not as “romantic”, the Power quote should be :• “The correct information applied to the correct leverage point at

the correct time for the correct duration is power.” – DP Harshman

• By the way, this also defines, in many ways, the decision making process

• These days, information is coming at us so fast that it is “almost” useless

• To put that flood of information to work, you either need:• A whole lot of time on your hands, or

• IT’s services

From Idea to Execution ... 6

What IT is … (cont'd)

• IT is there to provide and support systems (e-tools) that help you and your business do “things” better, whatever that information “thing” is• System, defined: loosely, any application, more precisely the entire

package – comprised of layers:• Infrastructure (telephony, networks, datacenters, etc.)• Hardware (subset of infrastructure but separate too – switches, routers,

etc., as well as the physical computers)• Software (operating systems, application development toolkits,

applications)• Training (manuals, on-line courses, webinars, etc)• Support (service companies, help desks, friends, cube-mates, etc.)

• Typically, IT is business related (roughly 90%) but the above also applies to remaining 10%: science, leisure time, etc.



• All IT groups have / need the following business functions:

• The production side of IT will look something like this model:


What IT is … (cont’d)

• Of course, the above IT organization chart manifests itself in many ways in “the real world”

• However, all of these functions must exist, one way or another, and be managed (one way or another)• By the way, no part of the IT organization is more important than

the other …

• … until it ceases functioning (or is omitted entirely)

• This is important to know because directly, or indirectly, you will work with one or more of these IT functions

• It is equally important to know what IT is not …


What IT is not …

• As a nearly iron-clad rule, unless part of a “software house”, IT is not a profit center• Treating it as such can be destructive, taking IT off its purpose

• Only on rare occasion does IT develop products that can be sold in the marketplace (it happens but is not typical)

• But. IT is a cost center and must justify its existence by providing a return on investment … for the company and its customers

• IT will not run your business. That is not its purpose either.• IT is there to support the company and the company’s Product Life

Cycles … not take them over

• So how do you work with IT?


Your Approach to IT …

• “Just Do It” is not an order you ever want to give to IT• That is virtually guaranteed to get you what you don’t want

• As you know your business better than IT, you must be willing to, and have the patience to, transmit your knowledge and experience to IT … to get what you want• If you want an ROI from IT you need to invest in IT … starting with

your time

• Just as there is no “quick fix” in business, no “quick fix” in taking your idea to market, there is no “quick fix” in IT• It takes work. Hard work. Quality work.

• Sometimes there are mistakes. If so, admit it, fix it and move on.


Your Approach to IT … (cont'd)

• Don’t “cowboy” solutions, don’t “shoot from the hip” and buy software/systems on a whim … work with IT instead• More bad software and poorly envisioned systems have been

bought without reference to IT than you would believe … billions and billions of dollars … and an uncounted amount of time

• “Whim” purchases generate massive waste and unnecessary CAPEX and/or OPEX costs because of (in part):

• Architectural compatibility issues with existing hardware / network / infrastructure

• Version compatibility issues

• Security issues (leaking, missing entirely, half done, etc.)

• Interface issues (data to/from other systems)

• Quality issues

• Audit control issues


Your Approach to IT … (cont'd)

• Similarly, don’t believe all the hype you read in trade magazines, or hear about at seminars or conventions …• The latest and greatest is said to be on the “bleeding edge” for a

reason

• Don’t initiate IT purchase research cycles with “your mind made up”• You and IT need to partner, do your homework together

• Assume the first priority of vendors is their company not yours

• With high risk concerns, if not absolutely 100% sure, you need to participate in “proofs of concept” or “prototyping” or a “pilot”

• Your IT systems are business investments, treat them like one• It is far cheaper to say “no” before you buy than “oops” afterwards


How You and IT Get Things Done …

• Just as a company or business area has processes and procedures, IT has its guidelines for getting work done

• After you’ve roughed out your idea (you’ve drafted or doodled the 50,000 ft details), what it will boil down to is the creation of a project to design, build and implement your bright idea

• This will be done within a framework of 4 IT Life Cycles• Whether any or all of these Life Cycles (progressive changes of

state) are known, they always come into play … for better or worse

• The following graphic is from “NotesOn: The Four Fundamental Life Cycles Of IT” 2; very briefly:


How You and IT Get Things Done … (cont'd)



• Let’s focus on the Software Development Life Cycle as that is one you will be intimately involved in with IT

• The first thing to know is that there is no exact, rote, cook-book type project / software development process that uniformly deals with every single IT project and task• How a project is executed varies, depending on the scale (size) or

degree of complexity of the project, or both

• If you find a Project Manager who only uses one by-the-book approach to every IT project, no matter what, you will (not may but will) have problems sooner than later

• It takes experience to be an IT PM and to drive a software / system development project (a subject worthy of another course)



• Project Execution Background• There are two basic classes of projects:

• Feasibility Projects – when there are too many unknowns to estimate “everything” or even most everything with reasonable accuracy

• Execution / Realization / Production Projects – when most of the elements are known with a fair degree of tolerance

• Note: no project in the planning stages (save for perhaps the very simplest) is ever “dialed in” with 100% accuracy

• These two can be and often are renamed, they can be broken down into smaller project types (bug fixes, tasks, minor enhancements, etc.) but no matter the type, the fundamentals are the same

• The fundamentals are just scaled (up or down) as appropriate



• All projects are (should be) held in check by three elements (known officially as the “Triple Constraint”):

• Scope – the results / limits set for the project

• Time – hours (work done) and calendar periods (duration)• Note: also known as “Schedule”

• Cost – expenditure of energy and resources in terms of $’s • Note: it is more than just labor rate x hours plus purchases

• An expanded version of the Triple Constraint exists, adding:• Risk• Quality• Customer / Client / User / Stakeholder satisfaction

• These “metrics” are used to help guide you, and IT, through the process



• Project Execution Fundamentals• As an IT client you (really) don’t care how IT gets “it” done

• However. There are (as a minimum baseline) items you need to see as your project moves along

• Project Charter:• Defines the purpose of the project (compass bearing)

• a.k.a. Business Objectives, Goals, Vision Statement, etc.

• Names the “project champion” and the stakeholders and their roles• One method is to use a RACI chart, with each stakeholder assigned to a

role: Responsible, Accountable, Consulted, Informed

• Grants authorization for the project (perhaps a feasibility study first)

• The format can range from the “header area” of a simple work order to a formal multi-page document with “wet signatures” (i.e. with a pen)



• Project Scope• This document is based on information gathered, and assumed, in the

very early phases of bright idea generation, plus from very broad initial requirements gathering

• Lists what is “In-Scope”, ex: the automation of the A/R process, …

• Lists what is “Out-Of-Scope”, ex: the A/P and G/L processes, …

• Includes assumptions (pro and con), ex:• Key users and stakeholders have committed to a minimum of 10 hours per

week for interviews, reviews and testing

• All necessary IT resources exist – no new hires, hardware or software

• Named IT and other personnel are committed to the project 80% of each week until completion

• Named IT personnel will not be assigned to other projects until completion and roll-out



• High Level Requirements, ex:• Business Requirements

• Existing Processes & Procedures (PnP's) – how its getting done now

• Desired Business Process changes / improvements – the bright idea

• High Risk Issues (what keeps them awake at night)

• What MUST the system do

• What would be NICE for the system to do

• Technical requirements • number of users and their distribution,

• system performance (minimum requirements),

• data flow and data storage,

• audit control constraints (SOX, PII, PCI, etc.),

• security constraints,

• architectural constraints,

• etc.

• Application of Triple Constraint



• High Level Design / Proposed Solution• High level cut at the design

• Design approach / strategy

• Preliminary architecture (web, client-server, scope of hardware, etc.)

• Preliminary Business Process (BP) changes,

• Optional (if high risk areas): draft user interface models (screens/pages)

• Etc.

• High Level Project Plan / Schedule• Broad strokes, not too detailed

• High Level Estimate (CAPEX / OPEX)• Includes contingency values (a.k.a. “fudge factors”)

• Draft Project Organization Chart – from champion to most junior• Project Personnel (tentatively) named



• Risk Analysis – Risk Management Plan, includes:• Risks Identified (Vulnerability-Threat Pairs)

• See: “NotesOn: Risk Management – Risk Analysis” 2

• Mitigation Strategy for each Risk:• Mitigate it – ex: prototype / proof of concept of high risk element• Avoid it – ex: use different development tools / environment• Transfer it – ex: bring in an experienced “guru”• Accept it – ex: setup additional contingency reserves (self-

insure)

• On large projects there should be a formal Risk Analysis – Risk Management doc

• On minor (small) projects the risks should be noted within the Design / Solutions doc

• If you don’t see risks and mitigations listed … ask for them



• Approval Gate (Go-No Go, Green Light, etc.)• An executive summary document is often assembled (especially for

“big ticket” items) containing the “presentation version” of the above.

• The doc has many names, ex: Project Authorization Request, Capital Expense Request, Project Proposal, etc.

• If the initial project was a Feasibility Study, the approval sought is to move to the production project.

• All key stakeholders should be involved in the review meeting

• The goal is to obtain “buy in” from all stakeholders such that they know, and agree, on the next steps and the targeted end result

• With the caveat that the high level estimates may change and be refined as the detailed requirements, design, build and testing phases are done

• “Wet signatures” are very much desired



• Detailed Requirements• No set of requirements are 100% (except very small projects/tasks)

• However. You need to be as accurate as you can manage … before construction

• Some iteration will naturally occur as you and IT delve deeper:• From High Level: business process / work flow

• To Middle Level: individual use – user stories, use cases, etc.

• To Lower Level: “nuts and bolts” details – “where do I enter …”, “where do I get …”, “how do I …”,

etc.

• More questions will come up during Design & Build …• But. Do not let that be an excuse, do not accept “we’ll figure it out later”

• Define and refine until you are comfortable there are no critical omissions

• This is where the “sweat equity” really kicks in … • “The devil is in the details”

• For a new “bright idea” project, if it’s too easy “something ain’t right”



• Map out the standard processes then look for the exceptions• The exceptions will kill you if you don’t find and plan for them

• Do lots of “What if …?” Virtually nothing is too outrageous to at least consider

• No one should be restricted from raising their hand to ask even remotely relevant questions or make a suggestion

• Do NOT focus on architecture at this point (languages, databases, server types, network “stuff”, etc.)

• Don’s Rule #1: “The thing you learn first is ‘The Best’ until you find something better … or more appropriate.”

• Don’s Rule #2: “The right tool for the job … is the right tool for a reason … but you won’t know that if you’ve decided ahead of time.”

• You and IT are gathering detailed requirements at this stage, not designing, so first gather , then design

• Design ideas will “pop up” but note them in a margin for the time being



• As we saw above, there are two classes of requirements• Business Requirements, ex:

• Every business case, user case, you can lay your hands on• Exception handling (the 20% ± outside “normal” PnP's)• Data inputs, data processing / transformation, data outputs• User access requirements / restraints, security• Reporting / Business Intelligence• Dashboard Requirements• Archival strategy (legal, IRS, corporate, etc)• Disaster Recovery / Business Continuity

• Technical Requirements, i.e. the behind-the-scenes IT details, ex:• Performance benchmarks• Data backup requirements• Security requirements (system and data)• Disaster Recovery• IT Audit Controls (SOX, PII, PCI, etc.)• Risk Mitigation • User Interface “look and feel”, navigation, graphical standards• Etc.



• Approval Gate• Review Detailed Requirements (Business and Technical)

• Again, the expectation is not “100% absolutely accurate” spec.s, but you and IT should be more than “close enough for government work”

• If this process goes “round and round” a few times, that’s fine, in fact that is as it should be

• Despite the way we are discussing it, the project process is not “once through and that’s it” … it is an interactive iterative inquiring process

• It is far cheaper to change/add to a requirements doc than to change code

• Just make sure all stakeholders keep in mind the Triple Constraint



• Detailed Design• Don’s Rule #3: “If you can’t design it in two dimensions, you can’t

build it in three.”• i.e. if you can’t draw it, diagram it, model it, etc. you’ll never build it

• A number of “cutting edge” SDLC methodologies propose ignoring or seriously shortening system wide requirements gathering and overall design in favor of “just getting on with it”

• The assumption is they can gather requirements and do design and build as they go, i.e. on the fly, iteratively

• This approach works okay on small tasks / minor enhancements to existing systems where the architecture and code are well known

• It does not work well on major projects, especially “from scratch” ones

• You and IT need a road map, a blue print, for major projects or you will both wander in the forests and deserts for months, or years

• The road map is never 100% accurate but wandering is very expensive

• “Do over”, let alone “re-do over”, can easily blow the budget



• The build can be iterative, i.e. object by object, module by module, but at least take a strong first pass at requirements and design

• Design against overall requirements (the compass)

• Build against an overall design (the blue print)

• Tweak both as “fine tuning” questions come up (vs. major surgery)

• There will be plenty of “looping” between these phases (requirements, design, build) on “from scratch” projects without adding extra

• Design documents should include at least:• New business models(s), a.k.a. business / work flows

• Architecture design solution (now you need detail, diagrams, spec.s)

• Data models / diagrams – include examples of the changes made to data, especially exception handling / processing

• Models of pages, windows, pop-up‘s, etc. with usage data and rules

• Object models – even if not 100% accurate if they’re named and listed them it proves someone has thought it through

• Updated Project Plans / Schedules / Resource loading / Estimates



• Approval Gate• By the time you have read through the Design doc you should have a very

clear idea of what is to be built. Look for:• Scope creep – things you didn’t ask for that are there, or that you asked for that

aren’t• Missing components – “things” you or IT forgot to bring up or jot down• If the design doesn’t “feel right”, it probably isn’t

• The time invested in requirements and design is more than paid back by a cleaner, much easier, build

• The relative cost of a requirement found at each phase is roughly:• Requirements 1X 1:1• Design 7X 10:1• Build 50X 100:1• Test/Post Delivery 100X-1000X 1000:1

• Iteration is unavoidable, unnecessary iteration is expensive

• A look at a (very rough, work-in-progress) SDLC model, may help:



• Approval Gate (cont'd)• First, avoid your own tendency to add more “bright ideas” at the last

minute:• You, too, are learning as you go, so be aware that the process generates

new ideas … but acceding to all, maybe even any, can blow your budget

• If it is a major “must” issue , get it added or fixed• Might need to negotiate against the Time and Cost constraints

• If it is “nice” but can wait until “the next version” then let it• Don’t forget to add it to the Wish List

• And, before giving the “okay to build” make sure you are comfortable with the proposed design (and requirements).

• Yes, there will be changes (often based on “I have a question” from a developer) but start out with a level of comfort you can live with



• Build / Test• Again, you (really) don’t care how IT builds “it” (language, platform,

etc) as long as it seems (and is) rational• You are not the IT architect

• You are not doing the coding, no matter how “itchy” your fingers get

• You are the professional in your area … let IT be the pro’s in theirs

• Of course, common sense applies, hence all of the Approval gates

• Build / Test can be and often is phased and necessarily iterative• As it should be, but IT shouldn’t get so carried away “it” never gets built

• Constant iterations have a gradually accelerating negative effect on quality, stability, performance, and sustainability

• Keep an eye on constraints, if one departs too significantly, look for:• Scope creep (new requirements no change orders, ad lib requirements)

• Distractions to the teams

• Earlier assumptions proving to be incorrect



• As the “bright idea” generator, you must be part of the testing process, don’t even think about dumping that off to someone else

• There are three general classes of testing, in brief:• Unit testing – testing of each completed unit of code or code module• Integration Testing – proves (or not) that the pieces pass information and

commands to each other properly, meeting technical requirements• System testing – proves (or not) that the entire system meets all technical and

user requirements, including interfaces with external systems (ex: A/P and A/R and G/L and Finance Reporting)

• All three include load/stress testing, but it is of particular value during system testing as, here, you are trying to break the system

• Approval gate• Do not sign-off / accept it if you haven’t reviewed and tested• To be fair, don’t not sign off ‘cause you “thought of something else”

• If the Build meets Scope, Requirements, Design and any change orders, then accept it and add your newest “bright idea” to the Wish List



• Roll-out / Release• The minute you are ready to roll it out you will think of something(s)

“new” – new use case, new “must have” – … ignore the impulse:• If it is critical but not fatal, continue the release and add it to “The List”• If it is critical and fatal (this does happen occasionally), you and IT go into

over-drive (sometimes called hyper-care) to fix it• Name the requirement, exactly

• Re-engineer the design (don’t skip this), walking through all impact points

• Re-build, re-test, re-push

• Training / Implementation Plan• During the build phase, don’t forget user manuals, on-line help, etc.

• Inside a business, initial training is often done during the final build /test schedule so the users are ready to go

• There is often an implementation plan required as well, ex:• How does the system get pushed across the network or up to the internet

• How are any upgrades / bug fixes handled

• During testing were there compatibility issues found requiring special installation instructions



• Post Roll-out / Release• Monitor system performance and usage, IT helps with this

• During “hyper-care” this may need to be 24/7• Hyper-care, or equivalent, is a period (up to 90 days) when the original IT team

is still in “fast response” mode to any issues / problems /questions

• The same team that built it supports it, especially during hyper-care

• Talk to your users / clients – in person if possible• Gauge their reactions• Look at how they are using it• Always carry a notepad of some sort and any time a user / client has a

sensible request add it to the “Wish List” … let them see you do it• Let them know you and your IT team will review the request and schedule

a solution • Release / version upgrade periods are based on your business requirements and

the complexity of the system, ex: every 2 weeks, 2 months, 90 days, etc.

• Now, pat yourself on the back and enjoy your new system!


Final Notes …

• There is no such thing as ONE “Magic Wand” methodology that applies to all projects.

• Common sense must be used. Experience helps, greatly.

• Common sense applies to all phases from idea to execution

• If it doesn’t make sense, it probably isn’t sensible (or someone doesn’t know how to present it)

• If it doesn’t walk like a duck, quack like a duck, smell like a duck and taste like a duck …

• Don’s Rule #4: Even the most complex systems break down into simple, logical, components and rules … there may be a lot of them, but quantity is not the same as complexity

• So, if it, or some part of it, doesn’t break down, something is wrong with the information gathered and/or the assembly of the information and/or there is something(s) not yet known.


Q&A and References

• Questions?

• References:1 – see Wikipedia’s citations re: Thomas Edison quotes2 – as found on Don’s website: www.fromtherank.com

• Invitation:• I invite you to subscribe to my website (it is free)

• You will find additional (and numerous upcoming ) posts on IT

Thank you and I hope this helps,

DP Harshman


From Idea To Execution Denver University College Of Business 022310 - DP Harshman

Documents

Transcript of From Idea To Execution Denver University College Of Business 022310 - DP Harshman