2. OLD NEWS
• INFORMATION SYSTEMS WERE BUILT TO MEET FINANCIAL AND GOVERNMENT
NEEDS
• EARLY MACHINES HAD SOFTWARE BUILT INTO THEIR COMPONENTS THROUGH
MECHANICAL MEANS
• DATA EITHER MANIPULATED THE HARDWARE OR WAS AN ANALOG COMPONENT
3. REPEATABILITY
• PEOPLE LIKE COMPUTERS BECAUSE SUPPOSEDLY THE MACHINES, BEING
MACHINES, WOULD NOT MAKE MISTAKES
• UNFORTUNATELY, BEING BUILT BY HUMANS AND HAVING DATA ENTERED BY
HUMANS, THESE MACHINES ALWAYS MAKE MISTAKES GIVEN ENOUGH
REPETITIONS
• BUT DON’T BLAME THE MACHINES OR HUMANS, THEY ARE JUST ACTORS IN THE
STAGE OF PLAYERS
4. OBSOLESCENCE
• THE SECOND A PERSON THINKS ABOUT CREATING AN INFORMATION SYSTEM,
OBSOLESCENCE OCCURS IN THAT A PERSON NATURALLY WANTS TO CHANGE THE
INITIAL THOUGHT
• AS THOUGHTS START TO DEVELOP INTO CONCEPTS, CONCEPTS START TO CHANGE
• AS CONCEPTS GO TO DESIGN, THOUGHTS AND CONCEPTS START TO CHANGE AS
WELL AS DESIGN
• CONSTRUCTION OF MACHINE, SOFTWARE, OR A SOLUTION CHANGES AS THE TOOLS
CHANGE, FORCING THOUGHTS, CONCEPTS, AND DESIGN TO CHANGE AS WELL
5. METHODS AS SCAFFOLDS
• TO SUPPORT THE CONSTRUCTION OF COMPLICATED SYSTEMS, DIFFERENT
METHODS HAVE BEEN DEVELOPED OVER THE YEARS FOR DIFFERENT TYPE OF
PROJECTS, PROGRAMS, AND SUSTAINING MANAGEMENT
• BECAUSE OF THE NATURE OF COMPUTERS AND ‘INFORMATION SYSTEMS’ THERE
WILL ALWAYS BE ‘PROJECTS’ TO CREATE, IMPROVE, OR TRANSITION ‘STUFF’
• COFFEE AND ASPIRIN WILL BE SOLD IN BULK QUANTITIES AS A RESULT!!!
• NO METHOD IS BULLETPROOF
6. RUNAWAY SYSTEMS
• SYSTEMS THAT ARE BUILT IN A FAST ENVIRONMENT DO NOT CAPTURE THE
ESSENCE OF THE PROBLEM THAT THEY ARE USED TO SOLVE
• AS A RESULT THEIR PATH FROM START TO FINISH LOOKS LIKE A DRUNKARDS
WALK. THEY STAGGER FROM ONE OBJECT TO THE NEXT
• RUNAWAY SYSTEMS OFTEN HAVE EITHER A ‘COMMITTEE’ PLANNING THEIR
COURSE OR MORE THAN ONE SPONSOR CALLING DETAILED SHOTS
7. THINK, PLAN, EXECUTE
• A SIMPLE SOLUTION TO RUNAWAY SYSTEMS IS TO SIT DOWN AND THINK WHAT THE
OWNERS WANT, WHAT THE CUSTOMERS CAN USE, AND WHAT THE DEVELOPERS CAN
BUILD.
• THESE CONSTRAINTS WILL FOCUS THE ENERGY INTO A CONCEPT PAGE FOR
DEFINING THE REST OF DEVELOPMENT
• A SELECT GROUP OF SPONSORS, STAKEHOLDERS, AND USER EXPERTS MUST BUY
INTO THE PROJECT CONCEPT THAT USES TECHNOLOGY THE DEVELOPERS COMMIT
TO
• PROJECTS SHOULD NEVER EXCEED EIGHTEEN MONTHS, IF NECESSARY, ESTABLISH A
PROGRAM THAT BUILDS SYSTEMS THAT BECOME A SINGLE UNIT
8. TIME, TALENT AND TREASURE WITH A
PURPOSE
• IN ANY SITUATION, A PROJECT IS DEFINED BY TIME, TALENT, TREASURE AND A
PURPOSE. OTHERWISE IT IS JUST TOTAL CHAOS
• DO NOT PUT A ‘BEGIN’ DATE RIGHT AWAY, FIRST GIVE YOURSELF TIME TO
CONCEPTUALIZE WHAT TYPE OF ANIMAL YOU ARE CREATING
• BUILD A CONCEPT MODEL THAT DEFINES THE NATURE OF THE PROBLEM WITH
POSSIBLE SOLUTIONS. THEN SHOW PEOPLE THE CONCEPT.
• BEGIN TO PLACE INTO PROJECT SOFTWARE CHARACTERISTICS OF THE FIRST
EVOLUTION WITH APPROPRIATE TIMEFRAME, WORKERS, BUDGET AND TASKS
9. METATASKING
• THERE IS NO SUCH THING AS ‘MULTITASKING’. IT IS A CONCEPT THAT IS NOT
FOUNDED.
• PEOPLE CAN ONLY DO ONE THING AT ONE TIME, BUT THEY CAN SLICE THEIR
WORK QUEUE INTO CHUNKS SO THEY CAN WORK ON MANY THINGS ALMOST
SIMULTANEOUSLY. BUT DON’T OVER DO IT. YOU’LL START TO BECOME
OVERWHELMED OTHERWISE.
• USE PROJECT SOFTWARE TO ORGANIZE ACTIVITIES AND THEN START
DELEGATING TO PEOPLE ON THE PROJECT WORK THAT NEEDS TO BE DONE.
10. SPAN OF CONTROL
• MOST PROJECTS THAT INVOLVE CLIENTS REQUIRE MULTIPLE MACHINES AND MANY PEOPLE
• THE AVERAGE NUMBER OF MACHINES YOU CAN EFFECTIVELY WORK WITH IS THREE. A PHONE,
COMPUTER, AND A STEREO
• THE AVERAGE NUMBER OF PEOPLE YOU CAN WORK WITH DIRECTLY IS THREE AND THROUGH
DELEGATION SEVEN TO ELEVEN
• REMEMBER, MACHINES GET LOST, STOLEN OR BECOME BROKEN AND OBSOLETE
• PEOPLE TEND TO WORK AND LEAVE A PROJECT AS THEIR LIVES CHANGE AND CAREERS MOVE ON
• ALWAYS THINK ABOUT REPLACING EQUIPMENT AND SOFTWARE
• ALWAYS HAVE A STAFFING PLAN TO RECRUIT NEW PEOPLE
11. FRIENDLY FIRE
• ANYTIME THERE ARE TWO OR MORE PEOPLE WORKING A SYSTEM THERE WILL BE
DIFFERENT VIEWS OF THE PROJECT AND DEVELOPING SYSTEM
• IMPROVING PROJECT DELIVERABLES WILL REQUIRE IMPROVING THE PROCESS
• WORK ON THE PROJECT, THEN SUBMIT IT FOR REVIEW BASED ON DELIVERABLES
• USE THE REVIEW TO IMPROVE THE PROCESS AND THUS DELIVERABLES
• USE YOU OWN EYES, PEER REVIEW, AND EXTERNAL QUALITY ASSURANCE
• ALLOW FEEDBACK TO REDIRECT EFFORTS, RESOURCES, TIME, AND CHANGE
REQUIREMENTS
12. TECHNIQUES FOR PROJECT SUCCESS
• PROJECT CHAMPIONS MUST HAVE A SPONSOR THROUGHOUT THE PROCESS OF
SYSTEM DEVELOPMENT, OTHERWISE IT CAN BE A SHORT, SHORT EFFORT
• ISOLATE THE PROJECT FROM OTHER PROJECTS TO PREVENT KEY RESOURCES
FROM BEING ‘SHARED’ BEYOND USEFUL LIMITS
• KEEP PAPERWORK ON PROBLEM PEOPLE RECORDING THE ISSUE AND TIME OF THE
EVENT
• KEEP MANAGEMENT AND HUMAN RESOURCES INFORMED OF PROBLEMS AFTER
VETTING THEM WITH A PEER
13. ROLES OF SPONSOR
• THE PROJECT SPONSOR NEEDS TO DEVELOP A VISION
• THE PROJECT SPONSOR NEEDS TO HANDLE ORGANIZATIONAL POLITICS
• SECURING SEED MONEY FOR PROJECT
• PROVIDES TIMEFRAME FOR PROJECT
• ESTABLISHING WORK ENVIRONMENT
• ACCEPTS OR REJECTS ALL MAJOR PROJECT DELIVERABLES
14. PROJECT MANAGER
• DEVELOPS PROJECT CHARTER
• DEVELOPS RISK MATRIX
• DEVELOPS STAFFING PLAN
• CREATES PROJECT PLANS
• DEVELOPS FUNDING FOR PROJECT
• DEVELOPS CONTRACTS
• CREATES WORK ENVIRONMENT
• HIRES AND FIRES STAFF AND CONTRACT WORKERS
15. PROTOTYPE
• DEVELOP INITIAL SOLUTION BASED ON PROTOTYPING IDEAS INTO SCREENS, REPORTS, AND DATA
FOR PROCESSING
• DEVELOP FIRST CUT OF PROTOTYPE USING SIMPLE DATA AND SOME SCREEN AND REPORT
FUNCTIONALITY
• REPEAT THE PROTOTYPING WITH INCREASING COMPLEXITY OF DATA AND USER REQUIREMENTS
• CUT OVER TO PRODUCTION DATA WITH FINISHED SYSTEM
• MAINTAIN NEW SYSTEM AND LEGACY SYSTEM IN PARALLEL
• MIGRATE DATABASE TO NEW SYSTEM
• DECOMMISSION OLD SYSTEM
16. CLOSING PROJECT
• SHOWCASE PROJECT TO APPROPRIATE PARTIES
• CELEBRATE WITH STAFF PROJECT SUCCESS
• RESOURCE STAFF TO OTHER PROJECTS OR TERMINATION
• TRANSITION EQUIPMENT, SOFTWARE AND WORKSITE TO HOST ORGANIZATION
• WRITE CLOSING REPORTS
• WRITE LESSONS LEARNED
