I’ve sent once a new manager to attend a project management training class. (I always believed that a good software development manager needs to master the basics of project management). He came back and informed me right away that he knows what is “the problem” with our organization: we did not follow the PMBOK to the letter.
I remembered that exchange several years later when all my attempts to force a rational discussion on agile methods were silenced with references to the company’s “standard product development process”, with chapters that have not been changed since the days of the reign of the mainframe. Of course, today, the same organization claims to be “agile”, can’t verify since I’m not there anymore…
The point of these stories is that each process, documented or not, standard or not, needs to be derived from the latest body of knowledge and adapted to both the organizational capability and the task at hand. My new eager manager would have drowned in applying all the detailed directions provided by PMBOK, while my “mature” former employer missed many business opportunities by being non-agile on purpose.
Today I manage an innovation team, and the “right process” question is again on the table. Industry experience for innovation projects process is to either use the same process as for other product development activities (bad… kills innovation…) or to allow a “free for all”, “everything goes” attitude that treats innovation inside the enterprise as skunkworks and leaves teams alone to innovate in chaos.
The challenge is to find the right amount of process, something that helps achieve the innovation goals without creating unnecessary risks in delivery (think about developers not using a code repository with version control) or resource allocation.
After many years of managing innovation teams, I have developed a simplified framework for dealing with technology/software innovation projects.
I start with an http://ndapak.com/mixed-use-building-opf-housing-scheme-phase-1-lahore/ “Investigation Phase”, since most of the time these projects have no “requirements” in the traditional sense, but more of a statement of need or an “idea”. Not all projects need this phase, but if needed, it should be time boxed – 2 to 4 weeks max. I give time extensions on a case by case basis, but only after seeing significant progress.
The outcome of investigation is either a demo, a working prototype, or at least a report. Based on the results of the investigation, I decide to either create a new project, or add the newly discovered requirements to the “to do” list of an existing project.
From the “formal process” point of view, all that’s required at this point is a list of projects where we track progress on a weekly basis so we can monitor investigations that take too long.
Once I approve work a new project, we move to a http://justmusing.net/2007/06/10/looking-for-something-good-to-read/ “Project Inception Phase” stage, assign the development team, team lead, and document the internal stakeholders. The new information is just added as columns to the project list — still keeping the process at a minimum.
In this stage, the team needs to refine and document its delivery goals by creating a list of features, reviewed and confirmed with stakeholders, and set success metrics, even at a very high level. The process documentation now involves three lists: projects (weekly status, team, stakeholders), features, and success metrics — a very small overhead. Note how this simplified process is aligned with the GATE model (Goals / Alignment / Transition / Evaluation), only that less emphasis is given to the transition; focus is on goals, team (alignment) and success (evaluation).
The next phase is developing a project plan, including defining and reviewing the solution architecture and the development plan (milestones by month/sprint, total duration). Sprints are planned by project teams (e.g. two weeks, depending on backlog, project goals, etc…) and weekly progress reports are reported by team leads. In true agile manner, depending on project details, features can be adjusted (prioritized) based on sprints outcome.
At the end of the inception phase the project’s high level goals, features and direction should be clear.
Past these early stages, the process used for innovation projects becomes similar to any well run agile software development project in the “Development Phase” :
— Code repository (subversion),
— Issue tracking,
— Sprint backlog
— User feedback
— Deployment plan
And now you have it, it works and it’s going to revolutionize your company and the world… Many additional challenges lay ahead, and I will address them in another post.