Tag Archives: Project management

Boards on Quora: A new way to blog or manage projects?

Posted on December 19, 2011 | 2 Comments

One of my favorite websites, Quora, has launched a new feature called boards, which may put yet another nail in the blog’s coffin. Boards enable you to organize in one place Quora questions and answers, web links, notes and pictures on any subject you like.

It immediately occurred to me that boards were perfect places for project planning and management, kind of a virtual bulletin board where you can pin up whatever you like on a particular topic. That inspired me to start my first board: Learn to Draw and Paint. This is one of my goals for 2012, in an attempt to expand my creative outlets.

Boards would also make effective mini-blogs, on a subject as narrow or as wide as you wish. With tools like Quora’s Boards and Google+, it almost seems like we don’t need the blog anymore. However, the blog is still a great way to organize your stuff under your name on the web, all in one permanent place that can easily be searched, tagged and linked. Although I don’t update my blogs as much as I used to — and often, I am reposting content from another site to the blog — I still find the blog to be a handy way to keep a “home base” on the Internet.

→ 2 Comments

Posted in Geeking Out

Tagged , , , ,

Good reads on my blogs: April 2010 edition

Posted on May 7, 2010 | Leave a comment

I recently reposted some older stuff on this blog, from my days working in IT for a nonprofit. I did a bunch of posts on Getting Things Done that seem to be of interest. Most popular is my post on how to create a master GTD project list. Happy organizing!

Because my good reads post is scanty this month, I offer you some band name suggestions culled from search terms bringing people to this blog:

Friendly Dinosaurs
Obnoxious Venn Diagram
Thoughts to Sleep On

And this might possibly be my new blog name: Shannon In Between Blog.

→ Leave a comment

Posted in On My Blogs

Tagged , , ,

Why software development projects fail…

Posted on June 6, 2007 | Leave a comment

We are retiring some of the earliest software projects I worked on for my organization (yes, I have been here that long), some of which never achieved their goals or attained widespread usage. This got me thinking about why system and software development projects fail, and what we can do to mitigate these risks.

In my experience, there are two main reasons why projects fail (there are plenty of other reasons as well, but these are the ones that seem most prevalent):

  1. No one “owns” the data: No one is responsible, as part of their job, for entering the data and keeping it up-to-date. Everyone wants the data; no one wants to put the data in. For every project, we need to be very careful to identify who is responsible for owning the data and making that explicit. IT cannot maintain databases.
  2. The system takes too long to develop and is too complicated to maintain on an ongoing basis: This is probably the most crucial aspect of project failure. Our organization, like many, is subject to a heavy dose of “feature creep.” I’ve seen it happen every time — people get excited about a new system and imagine all the possibilities, which they identify as requirements. But all of these features are not all required for the system to do its intended job.

About each proposed feature we should be asking: Why is this needed? What problem are you trying to solve? Perhaps there is a simpler solution that the customer hasn’t considered. I’ve often seen customers get tangled up in how they are going to achieve something, when all they really need to define is whatthey are trying to achieve. We provide the expertise in the how, and we should strive to look for the simplest, most direct way. That’s where I find writing use cases to be really helpful in zeroing in on that simple solution.

In my experience, a simple system is more likely to be flexible and adaptable when change inevitably comes, and is more easily expanded or integrated with other systems. But even more important, when a set of requirements are simple, they are achievable in a shorter amount of time, people can start using the system sooner, and adoption will be higher. If customers have to wait through a long development cycle, they lose interest, look for other solutions, or otherwise become negative about the system.

Of course, there are other reasons for failure, as I said, but I think they are mostly tied to these two. Some that I can think of right off:

  • There is no executive sponsorship of the project.Employees take cues from their leadership, as they should; if something doesn’t seem to matter to the leadership, then employees will resist.
  • The user interface is not intuitive and does not match the user’s workflow. Again, use cases can really help with this. We should strive for zero training required on all systems.
  • The system does not integrate with the front-line workers’ everyday jobs. Ideally, each new system should replace an old job responsibility or in some other way make peoples’ jobs easier. Users will rebel every time if they see the system as something extra they have to do or something that doesn’t directly benefit them. If users feel they have to maintain the system and a shadow system to achieve their goals, they will definitely reject the system in favor of their shadow methods.

I have learned a lot from developing systems that failed, probably more than I would have learned in a course on software development or even in designing successful systems. The primary thing that I have learned is that system development is not really about technology or specifications or requirements. It is about people. Understanding how people work, what they need and what they want is the key to developing a successful system. No matter how much training and marketing you provide, you will never be able to make people use a piece of software that they can’t connect with in a basic way.

Reblog this post [with Zemanta]

→ Leave a comment

Posted in Notebook

Tagged ,

How to plan a project more effectively

Posted on March 17, 2007 | Leave a comment
IMG_4568Image by .nele via Flickr

I have been reading David Allen’s Getting Things Done (late on the bandwagon, as usual), and his chapter on project planning really resonated with me. My job is pretty much planning and managing projects. Officially, I manage software development projects, but I find myself managing all kinds of projects for the organization, some related to my role in IT, some not. So I am constantly on the lookout for a more effective way of planning projects, which often seem to get frustratingly stuck before we really get started doing things.

David Allen’s description of a natural project planning process makes perfect sense to me. The reason we get stuck is that we’re trying to do something unnatural. Usually we start with trying to figure out what to do rather than why we are doing it. Or we get caught in the trap of defining the problem with no ideas for how to solve it. And Allen is definitely right when he points out that when you don’t follow the natural planning process, eventually you fall into reactive mode, where you go through the process anyway but in reaction to a failing project.

The following is my summary of Allen’s natural planning process, with a couple of additions based on my own experience and learning in planning projects for an arguably dysfunctional nonprofit for the last four years.

First, what is a project anyway? A project is any desired result that requires more than one action to complete. A project could be development of a system or website, planning a meeting or conference, deciding on a new type of laptop or installing a software upgrade.

Project planning can effectively be done in one, two or three meetings, as long as the meetings follow the natural planning process in the order outlined below. This should result in all the output needed to produce a vision statement, project plan and outlines for other necessary documentation, such as business rules and use cases.

The seven stages of a natural planning process are:

  1. Define the purpose of the project.

    2. Why are we doing this project? What are our intentions? What problem are we trying to solve? What untapped opportunity are we capitalizing on? Be as specific as possible. The purpose will provide the focus for the project and also help guide you through the actions to complete the project successfully.

  2. Set the givens of the project.

    3. What are the constraints, such as time, budget, resource, technology, geography or legal constraints? What policies — internal or external — do we have to adhere to? What standards do we have to uphold for successful completion of the project? What expectations do we have of people working on the project? What other boundaries can we identify?

  3. Craft a vision of a successful outcome for the project.

    4. What will the project be like when it successfully appears in the world? How will we determine success? What will have changed when this project is completed? The vision should include clear, specific outcomes by which to measure success.

  4. Determine the stakeholders of the project.

    5. Who is affected by the project? Identify everyone who has an interest in the project, including all members of the project team. What are their goals that they want to achieve with this project? Are all stakeholders represented (if not, perhaps call another meeting)?

  5. Brainstorm tasks and requirements for completing the project.

    6. How will we accomplish the vision? This is a time to get all ideas out of people’s heads and captured. Do not critique or organize ideas at this point. Document every single idea. The goal is to figure out all the things that won’t work as well as all the things that will.

  6. Organize all output generated into a project plan.

    7. First identify the significant pieces generated during the brainstorming session and weed out anything that is not feasible. Then sort by one or more criteria: components, sequences and/or priorities, for example. Detail each to the required degree. This may be done during the planning meeting or by the project manager for presentation later.

  7. Identify next actions.

    8. Next actions are any specific, discrete tasks that can be accomplished now to move the project forward. There may be several next actions that can be done in parallel, or there may be only one upon which all subsequent tasks are dependent. Next actions may include additional planning sessions. Each action should be assigned to an owner with a timeline for completion, or an owner can be given responsibility for a component of the project and then determine the next actions for themselves.

    When one action is completed, the next action should be identified and assigned, if necessary. Assignment or review of next actions should be done at the end of each project team meeting.

Not all of these stages need to be conducted in a formal planning meeting or documented; that depends on the project. More formal or complex projects require the project planning team to complete and document each of these phases.

If a project is stuck, revisit these phases to determine where the blockage is occurring. For example, if you can’t determine next actions, you probably need to go back to a previous phase and make sure it is specific and complete. If you don’t have a vision of how the project will be successful, it is very difficult to determine what needs to be done to move the project forward.

Related articles by Zemanta
Reblog this post [with Zemanta]

→ Leave a comment

Posted in Notebook

Tagged , , , ,