• ADVERTISEMENT

    Project Management 101

    by Dan Schultz
    August 14, 2008

    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.

    ADVERTISEMENT

    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.

    1. Identify stakeholdersStakeholders 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.
    2. Gather requirementsRequirements 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 (e.g. users need to be able to upload and tag photos) but there are also non-functional requirements (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.
    3. Understand constraintsConstraints 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.
    4. 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?
    5. 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.
    6. 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, 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 so you don’t have to battle through this brave new world alone!

    Tagged: gethering requirements information systems project management

    3 responses to “Project Management 101”

    1. PM Hut says:

      Your six steps of success are mainly in the initiating and the planning phase (you’re missing 2 phases: executing and closing). If you don’t plan the project right, the project will definitely be a failure, but I don’t think your list is comprehensive.

      I am currently publishing a series on PM Hut ( http://www.pmhut.com ) listing 21 PM success tips: http://www.pmhut.com/?s=%2221+Project+Management+Success+Tips%22

    2. Dan Schultz says:

      Thanks for the response PM Hut and for helping to call out even more that this doesn’t take you to the end of the process!

      I would definitely suggest that people look into proper project management over the entire project life-cycle as they continue. I didn’t want to go into detail on steps after the planning phase because, well, by the time the project gets that far hopefully they will have hired somebody who knows this stuff like the back of their hand!

    3. Dan,

      I believe you set the tone of this Post with “Since most IdeaLab readers and writers are ultimately aiming to do exactly this in the field of journalism”. That’s a qualifier, in my mind, where ‘less is more’. Your “Six Steps for Success” do an excellent job of keeping the important in focus without adding too much overhead of a more exacting process.

      We coach people to think in terms of a process that fulfills three (overly simplified) key measures: 1) Practice outcome-based management (avoids the pitfall we call, “Good Plan; Flawed Execution.”), 2) Define gates or phases (in the process), and 3) Don’t try and leapfrog a milestone – a prototype is a good example of a milestone.

      In our experience, outcome-based management becomes the most important precursor to getting started. Without a clearly defined and measurable outcome, there is no reason to begin. In a like way, by defining interim points (gates) that must be met before the next step, like mile-markers on a hiking trail, you are certain to reach the next milestone (quantitative, not qualitative) in the project without gaps. Bypassing (leapfrog) a milestone can lead to undesirable results and otherwise sideline a good project. Lastly, there will be many gates and milestones to the project.

      Thanks for the good guidance,

      Peter

  • ADVERTISEMENT
  • ADVERTISEMENT
  • Who We Are

    MediaShift is the premier destination for insight and analysis at the intersection of media and technology. The MediaShift network includes MediaShift, EducationShift, MetricShift and Idea Lab, as well as workshops and weekend hackathons, email newsletters, a weekly podcast and a series of DigitalEd online trainings.

    About MediaShift »
    Contact us »
    Sponsor MediaShift »
    MediaShift Newsletters »

    Follow us on Social Media

    @MediaShiftorg
    @Mediatwit
    @MediaShiftPod
    Facebook.com/MediaShift