Project Managementfrom Both the Functional and Technical Sides

Thomas SkotteneNancy WalshOffice of Undergraduate Admissions

Funkies vs. TechiesDoes it have to be difficult?

Heard from the Functional Side

IdeaProject

ImplementationCode

Functional staff Technical staff

Projects tilted towards technical mind-set:• “Cool” features - No functional need• “What they really meant was this” – Arrogance• “No!! Can’t do it.” (with a lot of tech talk that

functional users don’t understand) - Rigidity

Heard from the Technical Side

IdeaProject

ImplementationCode

Functional staff Technical staff

Projects tilted towards functional mind-set:• “I didn’t know you needed that data” – Not enough detail• “Well, the system has to do that, so…” - Band aid design• “Oh and yes, we forgot about {insert module that changes

scope entirely}” – Incompleteness

In Defense of Both Sides

• It is difficult to identify all the details of a system/process that does not exist yet

• It is difficult to put together a puzzle if you don’t have all the pieces

• It is difficult to remember all facets of a problem

Project Challenge

Project

Coding

Language

Graphics

User Experience

Functional expert

Integration

How can we get everyone’s perspective and input, at the right time, with enough detail, and without wasting each other’s time?

Project Challenge

Project

Coding

Language

Graphics

User Experience

Functional expert

Integration

How can we get everyone’s perspective and input, at the right time, with enough detail, and without wasting each other’s time?

And not forget about anything!

Perfect?

“Have no fear of perfection - you'll never reach it.”― Salvador Dalí

“Strive for continuous improvement, instead of perfection.”

- Kim Collins

Essentials

• Knowing who should/needs to have input – Roles & Subject Matter Experts (SMEs)

• Following a process & defined timeline– Respect each phase

• Knowing what works – Tools & Techniques

Roles

Roles

• Project manager • Functional lead• Technical lead• Technical architect & Programmer • Editor• Graphics• User experience/Navigation• Testers – Staff and Outsiders

Project Manager

• Overall coordinator of project• Keeps track of the project timeline• Schedules & coordinates meetings when

needed• Works with all roles on the project• Manager may hold one or more other roles• Ultimately, responsible for project success

Functional Lead

• Most likely, has initiated the idea for the project• Knows why the project is being proposed• Knows the goal of the project• Understands the problems we are trying to solve• Responsible for conducting business process

analysis • Depending on scope of project, other functional

staff may be involved

Technical Lead

• The coordinator on the technical side

• Technical lead and functional lead should work closely together to ensure a successful project

• Technical lead can serve as a buffer between functional and technical staff; can speak both languages

Technical Architect & Programmer

• Technical architect:• Decides programming languages• Identifies tools and methods to use

• Programmers:• Write code (Java, .Net, etc.)• Configure software

• Databases• Configure hardware

• Firewalls• Routers

• System integration• Web service• Batch loads

Editor

• Develops text for emails, webpages, error messages, etc. associated with the project

• Make decisions related to grammar, spelling, and consistent tone/style of text

Graphic Design

• Creates the application’s look and feel through graphical elements

• Selects typography and fonts, overall layout and section position on screen

• Must keep the user in mind; is it an internal or external application being created?

User Experience/Navigation

• Designs the navigation and interactive experience for the user

• Focuses on consistency, user-friendliness and how to make processes intuitive

• Must keep in mind any accessibility regulations regarding online systems

Tester

• Internal testers• Verify that the system/application meets design

requirements (it does what it is supposed to do)

• External testers• Interact with the system/application prior to launch• Feedback can be invaluable

Process : The Fun Part!

Project Phases

• Initiation• Requirements• Design • Code/Develop• Testing• Deploy• Archive

InitiationWhy? & Who?

Initiation• Determine why the project is important to your office

– Save money/able to utilize staff resources differently– Speed up processes, automate– Improve quality

• Who are the internal stakeholders• Who are the external stakeholders - the audience

– Admissions example:• Students• Parents• High School or College Counselors

RequirementsWhat do we want to do?

Requirements

• Determine what is currently being done and how it can be done better in a new system

• Example: Create a back-end admissions review system which consists of the following modules:– User authentication– Integration with SIS – Automated tasks– Lists of work items– Interfaces to help complete tasks– Reports and audits

Requirements

• The requirement phase allows you to identify scope and what resources are needed; business process analysis

• If you know exactly what is being proposed you can better plan and help manage expectations

• It is often equally important to identify what you are not doing

• Requirements need to be defined as complete as possible

DesignHow will the project be implemented?

Design

• Find out how you will meet the requirements• Technical decisions

– Products (databases), languages (Java vs. .NET), Batch or real-time integration

• Functional and structural decisions– User experience

• Navigation• Language• Graphic design

– Coding• Database• Front end interfaces• Integration

Design

• Advantages of a thorough design stage:– Faster development since the direction is clear– Less confusion because the roadmap is detailed – Fewer frustrations as expectations have been set

• Great time to identify problems in the requirements since technical coding has not begun – changes are cheaper and faster

• Documentation of how system should work is vitally important (typically done by functional staff)

– Should be used in the testing phase

Code/DevelopNo time for questionsJust do it!

Code/Develop• Mainly turned over to technical staff during this stage

• Actual creation of product begins

• Technical staff will use design documentation, so….• If processes weren’t clearly defined in requirements/design stage, this

is when problems can begin.

• Functional staff patiently wait for a first glimpse of the product

• Continued dialogue between functional & technical is recommended

TestingDid we do it correctly?

Testing

• Verify that the end product does what you think it should• Testers will use design documentation, so….

• If processes weren’t clearly defined in requirements/design stage, testing will not go well.

• Develop a solid group of testers, including those who don’t know how the system should work

• Schedule ample testing time in your project timeline• Avoid launching a project which hasn’t been thoroughly

tested

The V Model of Testing

RequirementsSystem Test- Functional Staff- End-user Testing

Design- Technical design- User experience- Language and message

Code Unit Test - Developer

Integration Test - Developers- Functional and UI experts- Editors

The documentation for each step can be used to devise the test plansThe horizontal distance symbolizes distance it time

The vertical axis symbolizes the level of detail

DeployNow what?

Deploy• One of the most vital steps in the project timeline• Short-term deployment considerations:

– Downtime/transition of systems while deployment is occurring• Are previous systems still being used for certain processes?

– Adding users and access– Training & documentation

• Staff must understand how new system works in order to identify problems which weren’t found in testing phase

• Long-term deployment considerations:– Bug reporting and general change management

• New features and new phases/versions

– Technical and functional stewards need to be identified– Does new system allow for reorganization of staff?

Archive• Save off older materials to free up space and reduce

clutter• Allow for historical reporting• History typically repeats itself and an archive gives

you a head start• As you system evolves, make sure you don’t break

something old, when you do something new• Knowing why it was a bad idea the first time informs

why it might be a bad idea now

Tools and Methods

Tools and Methods

• Identify who the constituents are– Users

• What tasks do they do?– Use cases

• What should it look like or feel like?– Wire frames

• How should the constituents do those tasks? – Story boards

Identify Users and Tasks• The key is to trigger your imagination • Force yourself to look at an issue from many different angles• Create a team of people with different backgrounds, skill sets and

strengths• Identify users and tasks in the context of

– The org chart and organization’s mission– A map of the world, state, or city– Calendar – Your’s and the organization’s– The university/college websites– Agenda items for internal and external meetings– Presentations– Vendor Product Information– Mobile vs. Office vs. Home– Time of day– When you mess up, what do you do?– Things that aren’t on the screen like email and reports

Wire Frames

Wire Frames

• Pen and pencil works!• Other more electronic tools:• A Beginner’s Guide to Wireframing• http://webdesign.tutsplus.com/articles/a-beginners-guide-to-wireframing--webdesign-7399

– Balsamiq– Omnigraffle– Axure– Flairbuilder– Keynote/Powerpoint– Adobe CS– Fireworks– Illustrator– Indesign– ProtoShare

Storyboards

• Story boards are just a sequence of wireframes– Create multiple wireframes– Pretend to click buttons or links– “Open” up the new page or behavior

• Story boards can also just be a chain of written events where you ask: “What happens then?”

Storyboards

• Repeat as different user• Repeat with different goal or task• Think about what could go wrong• Show to “inexperienced” users and walk

them through and see how they respond – Ask things like “What do you think happens if you

click that button”

Challenges

• Jumping to “how” before “what” has clearly been defined

• Time crunch – Too much time spent on the {insert any phase} of a project

• Must follow project timeline: Project manager role

– The nerdy pie rule – Multiply whatever time you think it will take by

• Designing too rigid of a system that doesn’t allow for change

• Functional and/or technical staff not fully on board

Questions?????

Contact Information

• Nancy WalshDirector of Admissions Operationsnjwalsh@illinois.edu

• Thomas SkotteneDirector of Enrollment Management, Data Analysis and Systemstskotten@illinois.edu