Project Management 101

Whenever I tell someone that I'm majoring in Information Systems the response tends to be something along the lines of "Ahh that's nice... What's Information Systems?" For the first two years of my college education my answer was just "think of it as Computer Science lite." The real answer is much better: Information Systems is the art of applying technology to improve processes and help people accomplish their goals. Since most IdeaLab readers and writers are ultimately aiming to do exactly this in the field of journalism, I figured it might be nice to give a crash course in best practices. **The Million Dollar Questions** The first thing you learn in an I.S. class at Carnegie Mellon is that before you can effectively design a system you need to understand three things: * The People - Who will be affected by this system? What are their needs and desires? What are their current roles? * The Process - How do things work now? What can we do better? What do we want to do? What has to be done? What are our limitations? * The Technology - What technologies can we work with? What can they do naturally? What can we push them to do? These are the high level questions you should be asking when planning to do anything technology related, and you should have the answers long before a dime is spent on programming or design. If you dart into a project carelessly and/or wildly flailing your arms then chances are high that you will end up with an expensive failure. **Six Steps for Success** Addressing those questions isn't easy; in fact, I'm sure it is much like writing an investigative news report. You enter the process with a high level concept and you need to dig down into the details, adapting your vision along the way. The key, though, is that it is much cheaper to adapt _before_ there is code to change. With that in mind, here are the steps that will help you get ready to develop. # **Identify stakeholders** - "Stakeholders":http://www.isixsigma.com/dictionary/Stakeholder-127.htm are "people who will be affected by the project or can influence it but who are not directly involved with doing the project work." This might be readers, reporters, editors, community members, etc. The list will be different for every project and you will probably add more as the idea develops. Thinking in terms of stakeholders makes it easier to keep the needs and backgrounds of different kinds of users in mind, which in turn makes it easier to design an information system that will be helpful to everyone. # **Gather requirements** - "Requirements":http://en.wikipedia.org/wiki/Requirement are "statements that identify a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user." In other words, what does your system have to do? This includes "functional requirements":http://en.wikipedia.org/wiki/Functional_requirements (e.g. users need to be able to upload and tag photos) but there are also "non-functional requirements":http://en.wikipedia.org/wiki/Non-functional_requirement (e.g. the website needs to process all requests in less than 5 seconds). You'll have your own ideas, but never assume that you have all the answers; after interviewing stakeholders you will realize that their needs are different from what you would have expected. This is, by far, the most important part of a project's lifecycle since it will shape just about every decision; unfortunately, it is also the easiest to botch simply because people aren't good at clearly explaining what they want. # **Understand constraints** - "Constraints":http://www.agilemodeling.com/artifacts/constraint.htm are "restrictions on the degree of freedom you have in providing a solution." How much money can you spend? Do you have a strict deadline? Can you hire people with new skill sets? Is your website already using a particular piece of technology that you will have to keep supporting? All of these are limitations which need to be considered while deciding on a final solution. # **Research technologies** - There might be something out there that can help you do what you want to do; in fact, there might be something out there that _does_ what you want to do. Each project will have its own unique technology needs based on the requirements and constraints you identified, and researching the landscape will enable you to select the best solution for your special case. This can save a lot of time and money down the road, so please, do your homework and avoid the kool-aided urge to skip this step and just jump to the latest buzz-on-the-street tech! Some things to consider while looking at a technology: What needs of yours will it meet? Is it overkill? How new is it? Is there a support community built around it? What are people saying about it? What are _developers_ saying about it? What other sites are using it? How are they using it? Will you have to hire or train people? # **Brainstorm solutions** - By now you know what you need to do and you know the tools that are out there. Figure out all the different paths you can take to get where you want to be without violating any constraints. For each item on your list come up with pros, cons, and (if possible) estimates for the amount of time and money the solution would cost. For instance, when creating a brand new website one solution might be to hire an external firm that develops Drupal systems. Another might be to hire Ruby programmers and create the site in house using Ruby on Rails. # **Pick the best solution** - You're going to have to choose one to run with. Before you do, though, minimize unanswered questions. It is very inexpensive to learn more early on - it is much worse to realize 6 months down the line that you made the wrong choice and could have finished the job with half the price or in half the time. Do you know that the technology can do what you want it to do? Are you sure your staff can learn the skills required? Will your stakeholders actually approve of this solution and use the darn thing? To help this effort it might be helpful to do a "prototype":http://en.wikipedia.org/wiki/Prototype, which is a quick, cheap version of your system designed to answer your questions and, in project management jargon, "mitigate risks." Once you have done all this you still have plenty of work to do before anyone should start churning out code. This should get you started, though, and it will make it much easier to talk with developers and contractors down the line. Now, "go hire an Information Systems student":http://www.pbs.org/idealab/2007/10/an-outsiders-perspective.html so you don't have to battle through this brave new world alone!