Project Management for Inconsistent Development Efforts

Question

I am a CS grad student, and I am interested in applying project management or software/system engineering methods to research projects at my university. I have experience applying the Scrum framework for small development teams, but I do not believe such a management framework would be applicable here. Let us use Project A as an example.

Here are some characteristics of Project A:

• Roughly 50-75% of the effort of Project A is a technical solution that includes aspects of electrical engineering, physics, biology, chemistry, and computer science.
• Ideally, the initial effort of Project A would take less than a year to complete
• Anywhere from 2 to 12 people may be working on the project at any given time, with each individual having their own schedules and priorities
• The time commitments from each individual could vary widely (an administrator/professor might commit a few hours a week to facilitate the allocation of resources, another professor may be writing the research paper, a grad student may be involved for 40 hours a week for a few weeks in the summer to write a program, another student may commit a few hours a week for the entirety of the year to integrate electrical systems, and so forth). It may be possible to hold weekly meetings of sub-teams, but monthly meetings would be more realistic (if meetings are even necessary)
• At this time there is not a defined set of requirements. There are some vague use cases that can be refined into functional requirements, but there would need to be a somewhat substantial effort to refine the system being development into sets of technical requirements.

Project A is still in its infancy (conceptual discovery phase, perhaps?). By applying software/system engineering or project management methods to this project I can vaguely imagine the facilitation of:

• communication among team members,
• the thorough understanding of functional requirements while implementing the technical solutions,
• coordination of implementation efforts,
• and the collections of basic metrics (such as person-hours, defects per person-hour, or others)

As I mentioned earlier, I do not think that Scrum would be at all applicable to manage the technical solution of Project A. My experience in implementing technical solutions involves predictable and consistent commitments of time, even if the teams are distributed geographically or across multiple time zones. However, I am unfamiliar with managing a project where people may intermittently start or stop working because they have other priorities in the organization (the organization being the university, in this case).

What methods of project management, development life cycles, or software/system engineering could benefit Project A?

Answer 1

Definition of a Project

Google's dictionary yields the following as the primary definition of a project:

An individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim.

The "particular aim" part is important. Without clear deliverables that provide value to someone (a.k.a. stakeholders) then it's questionable whether you can really call something a project.

The needs of academia will certainly differ from public or private sector projects, but even oure research projects require a certain amount of structure to succeed.

Not Yet a Formal Project

Based on some comments, some additional information about the proposed project was uncovered.

The various departments and colleges of the university are sponsoring the project by allocating resources, although a long-term goal would be to commercialize our findings/product. I could see myself and/or a professor managing the project in regard to facilitating communication, arranging meetings, and coordinating efforts. I am having a hard time answering your question on stakeholders. I could imagine that the professors and students working on the project are all stakeholders. The university itself is only a stakeholder indirectly through each department.

Whether you're using a formal methodology like PRINCE2, or a lightweight methodology like Scrum, projects always need some kind of formal definition of a project to function. In other words, you need some sort of project charter.

Based on the quoted comments, one may infer the following:

1. There are no defined stakeholders who will reap the benefits of the project and drive the definition of its features and deliverables.
2. While there are financial sponsors, there is no project champion whose job is to promote or defend the project within the organization.
3. A project delivery date has been determined (e.g. "less than a year to complete"), but no actual scope or deliverables have been defined.

In other words, it's a project in search of a framework and a purpose, rather than a process formed around a given goal. There are other missing pieces, too, but these are the big ones that should be addressed in some sort of formal charter.

Stakeholders as Prerequisites

Even a charter has a prerequisite: you need stakeholders who want something of value to be delivered. Whether that's Ph.D. students researching for a dissertation, a tenured professor preparing for a school-sponsored paper, or an applied-sciences campus providing fieldwork for its students doesn't matter. What matters is that somebody, somewhere needs to be driving this thing, or it's not a project.

In my opinion, based solely on the limited information provided, the aim of the project and its key stakeholders need to be somewhat self-evident as input to chartering this project. A formal Project Charter Document is the output of such a process, but if the project itself has no stakeholders and no aim going into the chartering process, it seems unlikely to succeed regardless of the project management framework you ultimately choose.

See Also

• Project Initiation Phase
• Project Definition Phase
• Starting up a project

"Best-Effort" Resource Planning with Kanban

With all of the foregoing said, if you can address the project-formation and dependency-tracking issues required to drive your project, then you still need a framework that provides you with the ability to use some kind of "best-effort" resource planning.

A modified Kanban system may be a good fit when your work-in-progress limits will vary widely during the project based on who can provide time commitments during any given time-boxed period. The real key to making this successful, though, would be ensuring that no work element to be pulled would ever exceed the minimum time available to any project participant.

If you can't decompose tasks to that level, and you anticipate work-units that will vary widely in size, then you will have a prioritization problem where work is pulled from the queue based on two factors: the current work-in-progress limit based on current throughput capacity, and the size of the user stories that can be completed within a given time period.

This is usually a bad idea, as it doesn't allow the work queue to be properly prioritized. Instead of popping work off the top of the stack in dependency or priority order, you may need to allow people to pull stories based on circumstantial criteria.

Nevertheless, if properly utilized, Kanban as a framework seems a good fit for projects where available man-power will vary widely. You can certainly do this with any methodology, but Kanban provides work-in-progress limits and averaged system throughput as simple tools that allow for elastic delivery estimates without heavy re-planning every time resource constraints change.

Your mileage may vary, but it's at least a place to start. Good luck with the project!

Answer 2

First, congratulations on recognizing that scrum would be a round peg in a square hole on the project structure you describe. Scrum absolutely requires time commitments.

You might consider Kanban. I have only read about it, but it seems to be a format that supports a looser availability of resources while trying to restrict waste of those resources to an absolute minimum. I don't have any references that I prefer for this so start with Wikipedia.

Regarding meetings, under no circumstances would I go with monthly meetings unless there is only one person doing any work on the project for a period of months. Bi-weekly should be a minimum target especially in cases where you have more junior people working on the project. Juniors members need questions answered, attention paid to keep them motivated to deliver, and oversight to avoid gold-plating. Maybe you should have more frequent meetings with those who need it.

Answer 3

At the very least, you need some kind of a project plan that records what will be delivered when, and the dependencies between these components. Without this, it is going to be really difficult to communicate with your team members and show them when they need to be producing an artefact that is needed by someone else. This will also help you to understand if the very loose arrangement of resource availability can even deliver what is required... "Joe is only available from February, and he is producing the widget document. But Jane needs the widget document in January..."

If you are acting as PM on this, you can use the plan as a communication tool, and also as a way of lining up your resources well in advance... Don't wait until mid-January to check that Joe is still available to produce the widget document in February. Because if he isn't, you need time to find another widget document writer.

So, what I am saying, is whatever approach you take, understand the dependencies, and plan around them.