IT Fundamentals - DP Harshman

1

IT FundamentalsSupersede ALL Methodologies

Presented by:Donald P Harshman

At the Burton Group Catalyst ConferenceJune 25, 2008

2

The Fundamentals of Fundamentals

• Fundamentals were first observed as possible common denominators, they were gradually codified and then tested repeatedly

• Fundamentals became the foundation on which the rest of a subject was (and still is) built• Note: but, after the initial knowledge surge too often they are ignored (or

never learned) and eventually are lost from sight

• When reminded of a fundamental one often thinks: “Oh, right, I knew that.” or “Everyone knows that!”

• I.T. too has fundamentals, built on decades of hard won (and often expensive) heads-down, hands-on, lessons learned experience

• But, “Houston, we have a problem”

3


• I.T. technology continues to evolve at a rapid pace, and

• We incur a new crop of IT graduates every year

• This is a recipe for disaster: loss of crucial knowledge and, equally important, loss of virtually all historical perspective

• Especially with new recruits, what is labeled “legacy” or “declining” or “over 5 years old” is ignored or looked down on

• What is labeled “innovative”, “cutting edge” or “new and improved” is snapped up without full inspection or appreciation of its impacts

• But, there is a law that is always in play: “buzz words”, “latest fads” and “new and improved” or “attempts to ignore” never change fundamentals

4


• I.T. is an engineering discipline (no matter what role you play)• When treated as “an art form”, when off-the-cuff “cowboy” solutions are

allowed a free reign, I.T. is unable to reliably do its job• Creativity in I.T. is valuable but only after the fundamentals of I.T. and

the discipline of engineering are known and understood … and used

• Sadly, directly applicable parallels from other fields of engineering are, these days, deemed to not apply to I.T.• Almost nothing else said about I.T. could be further from the truth.• No matter how many virtual (OSI) layers are inserted between users and

integrated logic circuits … I.T. will always be a field of engineering

• Whether building a home, a bridge, a railroad, a plane, a refinery, a telecomm network … or an I.T. system … fundamentals apply

• So, “Houston, we have an answer”: the Fundamentals of I.T.

5

I.T. Fundamentals

1. You must want to build systems … … to help your users do “things” better.

2. You must know what to build.

3. You must know how to build it.

4. You must build it.

5. You must know how well you are building it.

6. You must know when to stop building it.

6

Fundamental #1:You must want to build systems …

• This is, or should be, Why you are in I.T.

• This fundamental must be your passion, it must be why you get up early in the morning and stay late at night

• If you are here for any other reason than to help build systems then, bluntly, you are in the wrong profession

• The current average lifespan of a CIO seems to be 2-4 years (at any given company) before they move on• Why? My guess is transient CIO’s don’t have the passion to build

systems, and, as a result they make serious and expensive mistakes as they have no fundamentals (no compass) to guide them

7

Fundamental #1:You must want to build systems …

• The lack of this fundamental is one of my root causes as to why “everyone” in I.T. is going crazy with off-shoring• Loss of fundamentals = loss of standards = loss of clarity of

direction = expensive misguided decisions repeated • If you don’t know what you are doing, why, just give the problem

to someone else … the further away the better

• If you aren’t in I.T. to build systems you will waste time, you will waste money, you will waste resources and you will have a tendency to buy into every “fad” and “new idea”, whether it helps build systems or not• Transient CIO’s have done some of the strangest things, but

building an I.T. organization that can’t, or can no longer, build systems is the strangest of all

8

Fundamental #1:… to help your users do “things” better

• Our users, not $’s, are why we are (or should be) in I.T.• Yes, we must make $’s but that is secondary

• I.T. is not about “us”. • I.T. is not about constantly chasing the “cutting edge”• I.T. is not about perennially perfecting Processes and Procedures• I.T. is not about calling a bug a feature and letting it go• I.T. is not about telling our users we can’t deliver because

“____________”

• I.T. is about “them”. • First, foremost and always• We are here to help them do “things” better. Period.

9

Fundamental #1:… to help your users do “things” better

• If we’re not helping them do “things” better we are not doing our jobs• In 1985 Microsoft’s Windows created a world-wide “WOW”

because it made it “easier” for users to do “things” better• So far, Windows Vista hasn’t created more than a localized “oh

dear” here and there. Why?• IMO, MS lost track of the fundamentals, this one in particular

• Users only care that our systems do what they want when they want, and it had better be better than “before”.• Users don’t care about UI’s, API’s or XYI’s … they care about

(positive) results.• They do care about an actual Return On Their Investment (ROTI);

it must do more for them, whatever more is, than it cost

10

Fundamental #2:You must know what to build

• The hard-line definition of “I.T. Project Failure” is:• Over budget and/or• Over due and/or• Under performing (i.e. failure to meet scope and requirements)

• The primary root cause behind all of these is that the I.T. team did not know what to build and did not build it• They had “an idea” of what they wanted to build• They did not know what the user wanted built

• Short of organizational sabotage, strip any failed project down to the bone and you will find the above to be true• Sometimes the user doesn’t know either, but that too is our fault

11


• The Truth is: it is not hard to learn what you need to know to build a successful system• It is (and should be) somewhat time consuming• It does require discipline• It does require documentation• But the truth is, you just have to do it (no excuses or short-cuts)

• When you “know what to build”, the first Return On Your Investment (ROYI) will be the oft-sought “faster build”• By the way, successful does not translate to cheap or cheapest.

Successful is the user seeing a true ROI.• A $10M system is “cheap” if it legitimately returns $15M• A $150K system is expensive if it factually returns $100K

12


• So, do your homework! It will pay off.• In a PM class years ago the instructor provided this rule of thumb

to emphasize the cost of a missed requirement. Roughly, it was:• Requirements Phase 1• Design Phase 7x• Build Phase 50x• Test/Post Delivery 100x-1000x

• Another rule of thumb I’ve seen is this series of ratios:• 1:1• 10:1• 100:1• 1000:1

• Instead of coming up with schemes and methodologies to mitigate the cost of missed requirements … please, just do your homework

• Perfection is impossible but that is no excuse for not pushing the envelope

13

Fundamental #3:You must know how to build it

• Before beginning construction you must seek out and work out the flow of data from end to end• hint: database & data storage designs are critical; they are the

foundation of your system and must be rock-solid• hint: there are no systems (not even content-only web sites) where

the above is not true – all systems have data flows

• You must know all the data inputs; carefully mapping, measuring and monitoring them until you can describe them in your sleep

• You must know the desired end results (the data outputs), i.e. for what, exactly, is the system’s data going to be used

• You must know the transformations that occur to the data in between the inputs and the end results

14


• The success of your I.T. system is primarily measured by how well it manages and manipulates data• It fails to the degree you miss inputs, overlook transformations,

fail to notice end results, and neglect data storage designs• The UI (and the “technical euphoria” behind it) is, at best, of only

secondary importance

• Spend the time to map out what you are going to build• Failing to know before you go is often fatal and always expensive

• An architectural/engineering dictum applies, in full: “if you can’t draw it in two dimensions you can’t build it in three”

• Build by module if you wish but map the whole system, first• The map is never perfect but the continuity and confidence it provides

your team is repaid many times in faster, more bug-free builds

15


• There is no applied field of engineering where the participants are allowed to guess at what the story is about, guess at how the story ends or even determine if it ends … except our “modern” I.T.

• The rule is: “You must have a clear, unambiguous, concept of where you are going so that you can figure out how to get there and … know when you get there.”

16

Fundamental #4:You must build it

• There are 100’s of ways to not build systems (and still look busy). Here are a few examples (you can find more):• Too many organizational layers between the project team and the

actual users (becomes interference rather than support)• Too much or too little paperwork for the task (wrong or no

methodology)• Too much or too little attention to the methodology (deliverables

become more important than the project, or are non-existent)• No project manager (the technical team will figure it all out)• No trained project manager (PM’ing is every bit as much a, non-

intuitive, experience dependent skill as Design and Development)• Technical decisions made by non-technical I.T. members• Little or no upper management involvement where appropriate

(too busy, never asked, …)• Violations of these Fundamentals

17


• Once the “blueprint” has been drawn up you must sit down, study it and plan out how you are going to build it• No contractor worth his/her salt rushes out to their supplier to buy

“stuff” and then starts slapping “it” together

• Study the requirements and design and then decide what tools to use• If you’re a .NET shop don’t assume .NET, Java might be the best

tool for the job, or vice versa• If its not a web application don’t force it onto the web just because

that’s what you know – client-server is much more secure

• Work out your resources, if you don’t have them get them• Bring in expert contractors who can mentor your team if needed

18


• Let your team in on the “estimating fun”• They have to live with their answers• But ensure they don’t pad everything in sight or you lose control

• Don’t shy away from the risks, hit them head on• It’s what you haven’t thought of, or thought out, that will “get you”• On the bleeding edge? Prove it before you promise it! • Proof Of Concept (POC) anything that keeps you awake at night

• Then work out a plan of attack: knowing before you get going will save you a ton of $’s and months of frustration• You say you hate using MS Project? What you really hate is

thinking your way through a ton of chaos, a blizzard of questions and a forest of unknowns to reach a neat orderly professional result

• Well, welcome to I.T.

19


• Don’t build something else, build that.• To build “that”, you have to have a blueprint

• guessing what the next piece looks and acts like won’t get you anywhere but into trouble

• There will be enough questions raised while following the blueprint, so don’t add to the list by “free-handing” in changes

• adding features for free (i.e. no change control) because it would be nice to do can turn a great project into a failed project

• Don’t permit scope creep (one of the deadliest I.T. sins); not from your users, not from your team

• If you did your homework the change requests will be “nice to have”, but not required

• Add “nice to have” changes to the next version’s list or get the users to sign, in blood, the new time and cost estimate

20


• So, if you know what the users want …

• If you know how all the pieces will go together …

• You won’t need “forty” iterations: • To build what you thought the users wanted built but didn’t, • and to fix what you thought the users wanted built but didn’t• and to fix all the fixes to what you thought the users wanted …

• To be blunt, endless iterations to reach an “acceptable” deliverable are symptoms of missing fundamentals• Another symptom is user burn out; especially on large projects the

constant iterations drive them crazy too

21

Fundamental #5:You must know how well you are building it

• You know what to build, you know how you are going to build it, and you are building it, so … now what?

• The “now what” is, making sure your team is building what the users want built … so they can do “things” better

• The drill is: “unit test”, “integration test”, “system test”, “user acceptance test”, and then “the developers support it”• This is time consuming but necessary … if the system wasn’t

worth the time you wouldn’t be building it, so build it right

• Your first line of defense against bugs is the developers (the software engineers) but they are your weakest link

22


• Developers are the worst testers in the known universe • You cannot rely on them to say “it’s done and ready for prime time”

with any confidence (a few yes, most no). Because:• Developers test what they wrote the way they wrote it … and they

assume it is “bug free” or they wouldn’t have written it that way• They produce what I call “engineering software”, it works perfectly

if you use it exactly the way it was written

• So force them to think outside their “perfect box”. For ex:• Developers must abide by the “two hour rule”; if they haven’t

solved a problem in that time, they must “bounce it off” someone• Developers must have a mentor, a guru, who they can go to when

they have questions. Same for the “guru”, they need tech support• Train developers to unit test; they must define “expected results”

before they test and then compare the “actual results” to it

23


• Integration and System tests come next• Integration tests prove (or not) that the pieces pass information and

commands to each other properly, meeting technical requirements• System tests prove (or not) that the entire system meets all of the

technical and all of the user requirements, including passing information and commands back and forth to external systems

• Load/stress testing is part of both, but it is of particular use in System testing as here you are trying to break the system

• If you can afford it, have a separate team do both test sets. If not, you and your developers must do it• But no one tests their own code or modules

• Documentation and test cases are required for both types

24


• Next up is User Acceptance Testing (UAT)• From stakeholders to data entry clerks, the users must be involved;

but in such a way they can still do their jobs

• They must have and use test cases, which they help create, with known inputs and expected results

• Just “winging it” is a really bad idea and proves virtually nothing

• They test processes, they test procedures, they test minimum and maximum values, they test logins and exit methods, etc., and … they test the system by “just beating on it”

• You want them to try things that you and your team never imagined

• Finally, they must sign off on UAT, in ink, or you are not done

25


• But testing is not the only step in determining how well you are building it; we’ve only scratched the surface

• For example, part of the “how well” process is monitoring your team’s progress, from project beginning to end• Are they stuck somewhere, are they behind, are they ahead

• which is why padding is not allowed in the estimates, it masks problems; contingencies are for unknowns not sand-bagging

• Are they following the blueprint• code reviews and regular side-by-side demonstrations help prevent

“free-handing” and “free features”

• Part of the “how well” process also includes monitoring the users and your budget and risk mitigation and …

26


• There is nothing “off the cuff” about keeping track of how well your team, your project, and the system is doing• Hint: when it comes to building professional grade systems that

help the users do “things” better, do not hire from the “Wing-it Productions” resource pool

• Quality Assurance and Quality Control take work and the planning for it begins long before you start the build phase of the project

• There is more to know about this subject but as one more hint, do not assume the “techies” will do it all for you• They are, or should be, professionals but they have their job to do.

You as a Director, Manager or Project Manager, have yours and that includes monitoring “how well you are building it”

27

Fundamental #6:You must know when to stop building it

• Unless you’ve been in I.T. for a while, with a “bunch” of projects under your belt, you might not believe how hard it is to stop building a system and get it out the door. Ex:• Your software engineers love to tinker and tune• Your sales people love to give things away for “future” benefit• Your users gain experience as the project goes along too and they

too come up with “better” ways to do “things” better

• Assuming that you’ve built what was originally promised, you are doing yourself, your IT organization and the users a grave disservice … if you don’t call it done and shove it out the door as Version “x”.• No I.T. organization can afford to “tinker” forever• No user can afford to go without their new system for forever (or

they wouldn’t have ordered it)

28


• This is one of the harder parts of building I.T. systems. It is where you really get to work on your relationship skills because you have to be politely hard-nosed.

• Here are two experience-based hints that may help:• Throughout a project I talk about “The Wish List”, that I maintain.

• When a user has an idea they send it in or tell me about it, I write it down, they see me write it down and I save it … for the next version

• As we approach the release date I tell the users I won’t talk about what will be in the next version for at least 90 days. I tell them:

• the best way to determine what needs to be changed, and its priority, is for them to use the new system … I whip out the wish-list

• These work if you have applied these fundamentals and built a confidence bridge between you and your team, and the users

29


• But, how do you know when to stop?

• It is when you and your team have met all the carefully gathered requirements, matched the well thought out designs, and tested the entire system from end-to-end … such that it will help the users do “things” better • While, of course, staying in budget and on time

• Simple, right?

• It is if you’ve learned and applied your I.T. Fundamentals

30

Conclusion

• The above fundamentals can be translated as follows:• F#2: Project Initiation & Planning• F#2: Requirements Gathering• F#3: Design• F#4: Build/Construction• F#5: Testing/Quality Control• F#6: Delivery/Rollout

• Backed by the right motivation and training, if you apply these fundamentals well … you will successfully build systems that help your users do ‘things” better

• I guarantee it.

31

Q&A

IT Fundamentals - DP Harshman

Documents

Transcript of IT Fundamentals - DP Harshman