Category Archives: Project roles

Can Project Management be Agile?

I am surprised by all the different viewpoints I have seen since I posted Does Agile Project Management Exist? There are those who say that Agile Project Management is an oxymoron.  There are those that say it is simply management of Agile software development projects.  There are still others that consider it a philosophy or set of values, but not a methodology!  Please understand that I am not an Agile-hater.  My projects these days are mostly IT infrastructure.  I was a software developer for many years  and a project manager of software development projects.  I am not clinging to Waterfall or the “old ways” of doing development.  I just think Agile has been over-hyped and everyone has an Agile something if they are in IT.  Now project management can be Agile; or so it would seem.

Let’s start with the PMBoK definition of project management: “…is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements…”

This is a broad definition that goes way beyond Waterfall vs. Scrum.

Here is the manifesto from agilemanifesto.org:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Notice that this is specifically directed at software development, not project management.  Software development can be done outside the bounds of a project and not all projects are software development.

The only thing that might be seen as conflicting with project management is the statement “Responding to change over following a plan.”  Even this is accommodated by change control.  Some might say that this is saying that change should not be controlled.  I have seen many systems fail because of uncontrolled change, so I don’t think this is what was meant.  Being too rigid and preventing change at all costs is a bad idea.  This may be practiced in some places, but not many.  It is not something that is considered “good practice” by the PMBoK or related standards.

What this manifesto describes sounds a lot like what we did a long time ago, before projects were managed.  There were a lot of problems with this, but that is a topic for another post.

Here are the twelve principles (my comments in red):

Principles behind the Agile Manifesto

We follow these principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Good idea for software.  Can this be applied to a tangible product?

  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

This works for software, but does it work for tangible products like a bridge or even a house?

  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Incremental and iterative software development was done before this manifesto was written and since.  Still trying to see how it would apply to a tangible product.

  • Business people and developers must work together daily throughout the project.

That is ideal if you can get the business people to do it.  Not a conflict with any existing PM principle that I know of.

  • Build projects around motivated individuals.

That is ideal if you can get them.  Most PMs I have ever known would love this and try to get it.  No one says, “Give me some apathetic resources and we will get this project done!”  It is hard to maintain high morale in an economic climate where you can lose your job any day.  This principle does not tell us anything new.

  • Give them the environment and support they need, and trust them to get the job done.

If you have a competent and mature team this works great!  I always try this until I find out that they do not have the skills or experience needed to get the job done.  This is not often a problem.  This is what I would call a general management principle, not even a PM principle.  It has been done this way for at least the last 10 years in the organizations I have worked at.  None of them claimed to be Agile.

  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This is very true and is understood by every project manager I have met.  This is the reason for meetings that project teams often dislike.  Sometimes it is not possible however because of geography or people moving on to other jobs or projects.  Some documentation is also needed to retain knowledge.

  • Working software is the primary measure of progress.

This is a way of quantifying physical percent complete.  This has been used in many projects with tangible results like construction for a long time.  Measuring software is trickier though, so work percent complete or schedule percent complete is often substituted on software development projects.

  • Agile processes promote sustainable development.

Agile has processes?  This is not what some of its advocates say.  I believe that this relates to the next principle.

  • The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This is where Agile Software Development ceases to become a project.  A project must have a beginning and definite end and is a temporary endeavor by definition.  None of the customers I have met in my career would agree to this at the beginning.  It may wind up that way in effect, but usually not without pain.  This is the only principle that is incompatible with project management.  Software development becomes a business operation, not a project, when this is done.

  • Continuous attention to technical excellence and good design enhances agility.

This is a good software development and engineering principle.  It does not conflict with PM, but is not a PM principle.

  • Simplicity–the art of maximizing the amount of work not done–is essential.

The KISS principle of engineering right?  No one wants to do unnecessary work, and PMs don’t want that either.

  • The best architectures, requirements, and designs emerge from self-organizing teams.

This is often true in software development.  Sometimes the self-organization is painful however.

  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This is done at the end of the project or between phases on most projects.

Pasted from <http://agilemanifesto.org/principles.html>

My point here is that there is nothing new to project management here but there are a few things new to software development management.

IT Project Manager

What Does it Take to be an IT Project Manager?

There has been a lot of debate on LinkedIn.com about what an Information Technology (IT) Project Manager (PM) is supposed to do.   It is fascinating because there are so many different views on this.  It is up to almost 900 posts at the time of this writing!  There has been around 400 unique contributors to this discussion, so it has really brought everyone out of the woodwork.

What are the duties of an IT Project Manager?  What qualifications are needed?  Can a non-IT PM manage IT projects?  There is a wide variety of responses as you might expect.  Here is the spectrum:

  • IT PM must be the technical expert with some experience on projects
  • IT PM must have been a technical expert once and has been trained as a PM
  • IT PM must be familiar with the technical area, have technical experts on team, and experience as PM
  • IT PM must have some experience in IT,  have technical experts on the team, and experience as PM
  • IT PM should have some experience in IT,  have technical experts on the team, and experience as PM
  • IT PM must be experienced in PM  with technical lead on the team.  Exposure to IT would be helpful.
  • IT PM must be experienced in PM. No other qualifications needed.

I wrote about whether a project manager has to have technical skills a while back, not knowing how widespread this controversy was.  Which one is correct?  It depends on where you work.

Why such a diversity of opinion about this?  Hasn’t the Project Management Institute (PMI) laid to rest what a project manager is supposed to do?  The problem with any standard is that the broader it is, the less specific it becomes.  The PMI’s A Guide to the Project Management Body Of Knowledge (PMBOK) is very broad when it describes project management.  The position of project manager has come about in many organizations without PMI’s input.  Project management itself is thousands of years old(e.g. the Great Pyramids).  The rush to get Project Management Professional (PMP) certified seems to have happened mostly in the last decade.  The result is that project management has grown up differently in different industries and organizations.  PMI’s standards are compiled from common practices across these industries.

What do project managers do in your organization that is not described in the PMBOK?  Do they write code?  Do they troubleshoot technical issues?  Do they design a technical solution?  What about people issues?  Do they mediate conflicts between team members?  Do they investigate why a team member isn’t performing well?  Do they do any team building activities?  Please leave a comment here!

technical lead and pm

Does a Technical Project Need a Technical Project Manager?

Many organizations believe that projects of a technical nature (IT, engineering, etc.) need a project manager with technical expertise.  The technical expert can manage the project since they obviously know what they are doing.  The problem with this is the assumption that a technical expert is both capable and willing to manage people, schedules, and budgets too.  This may be the case but often is not.  There is no doubt that a technical lead must oversee the design and construction of whatever is being built, but this is not the same as project management.  Having been a software developer for many years then managing software development projects, I know from experience that it is difficult to do both jobs well.

Here are some definitions that clarify these project roles.

Technical lead– This person designs the product whether it be a building, car, or software package.  This person’s primary job is to make sure the product will work as specified.  This may include technical discussions and guidance for other technical team members.  It may also include specifying how the product will be developed if there is not a standard methodology in place.

Project manager – This person works closely with the technical lead to create a project schedule, identify risks and issues, control changes, report status to management, track the budget and schedule, etc.  This person must also possess soft skills to facilitate team communication, mediate team member disputes, provide motivation, etc.

The project manager and technical lead must work together as partners in executing the project.  If the roles are clear and not overlapping, this works well.

It is very helpful if a project manager is familiar with the technical jargon and culture of the industry that the projects are executed in, but the PM does not have to be the technical expert and it usually works better if (s)he isn’t.