Posted on

Agile Project Management Methodology

What is Agile Project Management Methodology?

There is lots of talk about an emerging approach to project management called “Agile Project Management Methodology.”  Agile Project ManagementUnderstandably, some may confuse this with managing an AGILE software development effort as part of an organization’s  SDLC (Systems Development LifeCycle). All caps will be used to identify the software development methodology).  Recently,  PMI (Project Management Institute) began offering a “PMI-ACP Certification” (Agile Certified Practitioner). Project Methodology Main Page.

I talked with several practicing senior-level technology, business, and various industry project managers regarding their understanding of “Agile Project Management Methodology.”  Each of these experienced managers had a different interpretation of what this might mean but none had actually implemented this specific approach within their firms.  However, one organization was in the early stage of adopting an Agile Methodology Playbook.

The consensus was that Agile Project Management Methodology grew from the desire to produce results (deliverables) faster and reduce bureaucracy and burdensome “administrivia.”  The respondents also believed that if a project was primarily a business process reengineering effort (i.e., how do we eliminate duplicate work efforts within an operations team?), it probably would not be using Agile Project Management Methodology.  Time will tell if this proves to be correct.

A quick overview of AGILE software development is in order here. It is an iterative application development effort where requirements and solutions evolve through collaboration among developers, business owners, stakeholders, project sponsors, and end users (clients).  This methodology was developed almost fifteen years ago as an alternative to the heavyweight, document-driven software development processes such as waterfall (application development progress flows from one stage to another, incorporating feedback).  Within AGILE, a well-known software methodology is Scrum. It identifies “sprints” to produce smaller deliverables (deliver software “early and often”).  Changing requirements are expected and there is close, daily cooperation and communication between business people and developers.  Team members are co-located team members when it’s possible.

Most organizations have their own specific project methodology and if AGILE is part of their SDLC, it most likely has been customized to meet the needs of that organization.

While AGILE has been successful in many instances, it presents challenges for very large implementations and in large organizations where a centralized IT team supports multiple business enterprises.  Technology teams typically have a good understanding of what AGILE means. But business users, project sponsors, and stakeholders may not be as clear.  So detailed planning and excellent communication are key to ensure agreement as to exactly what functionality will be delivered “early and often”, as well as the quality of that deliverable (i.e., what bugs will be fixed when, and how will they be retested?)

Additional challenges arise when an AGILE development approach, which may fall under Agile Project Management Methodology, is supported at the corporate level. This is particularly true when you’re implementing a new vendor-based software solution. Individual enterprises may need to continue following a waterfall development approach when they have older legacy systems with multiple integration points. This situation creates frustrations, conflicts, and costly regression testing.

Any methodology should be viewed as the framework within which a project manager executes solid project management skills. They tailor the methodology to the specific organization and actively manage process interactions (i.e., scope change will affect cost and require trade-offs).  Managing in an “agile” way has always been a core competency of successful project managers.  Adopting an Agile Project Management Methodology should not be interpreted as a way to do an end-run around controls. Nor is it a license to take short-cuts through the critical processes of project management, (initiating, planning, executing, monitoring and controlling).  Instead, it should be viewed as an opportunity to consider a new and, hopefully, improved way of achieving success.

It is still not entirely clear if managing an AGILE software development effort automatically qualifies as adopting an “Agile Project Management Methodology” approach. Perhaps there is now a broader meaning to this project management approach which may or may not involve AGILE software development. It may just infer producing results faster.   Hopefully this will be made clearer over time. It will be interesting to track this Agile Project Management Methodology and to note how it is improving overall project management execution and delivery. It must be evaluated from the perspective of the project team, project sponsors, stakeholders, and end users.

Agile Project Management Lessons Learned

At the beginning of your 4pm course, when you and Dick talk to design your program and what you want to learn, you will select case studies that fit the kind of projects you want to manage. Chose you course and then select the which specialty case study from business, or marketing,  or construction, or healthcare, or consulting.  That way your case studies and project plans, schedules and presentations will fit your desired specialty.

  1. 101 Project Management Basics
  2. 103 Advanced Project Management Tools
  3. 201 Managing Programs, Portfolios & Multiple Projects
  4. 203 Presentation and Negotiation Skills
  5. 304 Strategy & Tactics in Project management
Posted on

Project Templates

Project Templates vs. Re-inventing the Wheel

Project templates can be a big time saver as long as they fit your project and your organization. The best way to secure templates that you can use on all of your projects is for you and perhaps a couple of other project managers to develop them yourselves.  It really doesn’t take a great deal of time and often project managers can pool and compare the formats and templates they use for the project scope, charter, stakeholder identification and so on.  Designing a common template obviously requires a little bit of compromise but it will save time for the project managers and the sponsors and stakeholders who will use these documents.  However, you should avoid at all costs the Excel template called “Factories” that sells hundreds of templates that supposedly “fit all projects.” They do not.

Project Managers are creative people and that’s a good thing. Without creativity, we would not be able to structure a project or react quickly to project templatesunforeseen challenges. However, it is also human nature to try to customize and alter things until they totally look the way we want them to or at least bear our undeniable mark. Unfortunately, this practice is not efficient and it might actually hinder your project success.  That’s why you reaching consensus on project templates with your PM colleagues is the best course.

Project Templates Save Time

We all hate those forms that we have to fill out to get a project approved and we don’t like the client’s format for project status reports. After all, we are experienced project managers. So why can’t the client use our artfully created project templates for the scope, charter, WBS, and status presentation? Of course we develop a new form for each project. If you work in an organization that always develops everything from scratch, please take a minute to read through the list below of the benefits of standardization. On the other hand, if you work in an organization with lots of standardization, these points might help you appreciate all the forms you have available. Obviously, over-standardization is an issue. But for the most part, having a standardized way of organizing, managing, and documenting projects has at least the following benefits:

Shorter Start-Up Time

If everyone uses the same project templates, everyone knows what to expect. Let’s call it the McDonalds Principle: No matter where in the world you buy a cheeseburger from McDonalds, its always the same: Two buns, one hamburger patty, a slice of cheese, a slice of pickle, mustard and ketchup. Customers know exactly what they’ll get when they order a McDonalds cheeseburger.

The same holds true for standardized forms and processes. Everyone knows what is expected and things can be compared, matched, and so on. All the decision makers in the organization know where to find the information they are looking for so they can make a decision more easily. Moreover, if you need to train a new PM, it is easier to show him/her a set of similar-looking project charters and plans than it is to analyze a set of completely different-looking documents. Last but not least, using tools that already exist and that have been tested by previous PMs will make it easier for you to start the actual project work. You need not wast time designing something that already exists.

Easier Lessons Learned 

Each project or project phase should end with a lessons learned session. Standardized requirements documentation, status reports, and plans make it easier to point out flaws and actually learn from our mistakes.

Easier Estimation Next Time

If all the projects in an organization use the same standards, it will be easier for PMs to use historical analysis for their next project’s estimations because they can accurately compare the current project with a previous one. The point I’m making here is this: Standardization has its place. Obviously, there is an extreme to that, but I hope you get my point. When starting with a new client, why don’t you ask your client if they have a standard for PM documentation?

Until next time.

Posted on

Strategic Vision vs. Project Myopia

Too often project managers get lost in the minutia and don’t have strategic vision for the project. They don’t see the big picture of how the project deliverables will affect the organization as a whole. In our work with over 300 organizations, this is one of the biggest concerns that client executives have about project managers. That is particularly true of project managers with an engineering or software orientation. The executives’ concern is that the project manager does not see the customer or the product or the larger organization. Instead they dive headfirst into the barrel of technical details.

It’s important to understand your project’s role in the organization’s top level strategy for reaching its goals. Strategic visionThis is true whether you’re assuming ownership of a project that’s underway or starting one from scratch,  Without that strategic vision, your project runs the risk of satisfying its own ends but disappointing the organization and/or the sponsors that supported it.  And that’s not a good thing.

Sources of Strategic Vision

So how do you apply strategic vision at the project level and see the big picture?  As a project manager, you need to have a good grasp of your organization’s long-term goals.  Your project charter should provide that linkage and you may want to clarify that in the project plan by directly describing how the project’s desired outcome supports the strategic goal(s).  If this connection is not made or isn’t clear, you may be only a few well-intended—but unfortunate—decisions away from providing results that don’t meet the project sponsor’s intent.

Questions to Gain Strategic Vision

You should ask yourself the following simple questions and keep them in mind as you execute your project. They will help you maintain that strategic vision and keep your project on track.

1.  Exactly how does my project support the organization’s strategic goals?  How do the project’s requirements and deliverables relate to the strategic goals?  Consider how much flexibility the deliverables can bear before they no longer support the goal(s).  You may even establish a threshold beyond which the project should be reassessed and/or revised.

2.  How will my project’s success be determined?  Success criteria should be spelled out in your scope statement.  If set correctly, success criteria directly support the desired business outcome of your project. By extension, they support the sponsor’s strategic goals.  If you must adjust success criteria due to approved requirements changes, make sure this linkage to success criteria, desired business outcome, and strategic goals remains intact.

3.  Where does my project fit in the organization’s strategic activities?  View your project from the outside. From a broad, strategic perspective, how does your project align with other projects addressing the same or related goals?  There are both benefits to be gained and pitfalls to be avoided from this exercise.  For example, you may discover the potential for synergy with another project, or at least opportunities for mutual support of a strategic goal.  But you may also discover redundancy or interdependencies that must be acknowledged and dealt with.  At a minimum, you will gain valuable insight into the tactical role your project plays in supporting the overall strategic goals of the organization.

4.   What is the long-view of my project?  As project managers, we often become mired in the here-and-now issues that demand our immediate attention.  Without meaning to, we may lose the ability to see our project in the long-term and not recognize when we have strayed from our core purpose.  It is important, maybe even critical, to allow yourself time now and again to look far downrange and make sure that the course you are on isn’t leading to the wrong destination.

5.  Do I truly understand my project’s cause and effect relationships?  By dwelling too much on low level management of daily project operations, it’s easy to miss or underappreciate cause and effect relationships that stretch beyond that myopic perspective.  Problems you’re dealing with today may have roots far in the past, maybe even preceding your appearance in the project.  As a project manager with “strategic vision,” you’ll have the ability to step back and understand the full scope of that relationship. That will allow you to address it appropriately.

Posted on

Crisis Project

tomIt doesn’t matter if you are the most experienced PM out there or if you just started your career in this field. There will be times when things don’t go your way and  you have a crisis project. As a matter of fact, if things wouldn’t go wrong from time to time, we would not have an opportunity to learn from our mistakes. However, it is also important to remember that no matter what the situation, a good PM always turns to problem analysis and planning first, that’s good crisis management. Project Planning Main Page

Towards the end of last year, I was reminded of the importance of planning during times of crisis. We had just completed a smaller migration project. This project was a rather routine exercise, as we had done similar projects multiple times before. The objective of the project was to move a number of trading transactions from one book to another in our main trading platform. We had a standard plan for this kind of project, everyone had signed-off on the plan, we had a number of test rounds, and finally, we did the migration in our production system. And then came the crisis. During our initial analysis and throughout the implementation phase, we had overlooked a small, but rather important parameter, and as a result we had produced a little mess in our main general ledger. Needless to say that most of our users had a tendency to panic, and the first thought was to move into action immediately, and to just adjust the ledger manually. This would have taken a whole day, and it would have bound numerous resources.

So how do you convince a crowd not to just jump into action, but to first perform an analysCrisis Planningis and a planning session? You remind them about the consequences if the quick fix doesn’t work. The reason we had been in this situation was that we overlooked something before; hence, I reminded them that we don’t want to do the same mistake twice. Obviously, not everyone agreed, but most users understood the importance of analyzing the error and planning the response. So we did our analysis and created a simple “project plan”. This was not an endless document, on the contrary, it was an email, but a structured one. The email had the following sections:

  • Objective including a “business case”, which was the result of the error analysis
  • List of Stakeholders
  • Risks & Constraints
  • Procurement (we concluded that we can fix the problem ourselves)
  • A brief WBS
  • Communications Plan

During this “crisis” planning phase we discovered a very simple method of fixing the error, so the fix was truly “quick” and required a lot less time and resources than the original quick fix. Once the fix was implemented, I produced a lessons learned document and adjusted our standard plan for procedures like this. By following the standard project management during a crisis situation, we had forced ourselves to think first and agree on the way forward. In our case, the analysis part revealed a better solution, but even if we would have had to manually correct the error, we would have brought everyone back into the boat.

So next time something doesn’t work out as planned, remember that no matter what, analysis and planning are still the better response to crisis than a quick fix.

You learn all of those skills in our project management basics courses. Take a look at the basics course in your specialty.

[button link=”http://162.144.114.198/~jwkdwgmy/it-project-basics-111/” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/project-management-basics/” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=”yes”]Business[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/construction-project-basics-121/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Construction[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/healthcare-project-basics-131-2/” style=”info” color=”#1e14a8″ window=”yes” bg_color=”00000000″]Healthcare[/button]

[button link=”http://162.144.114.198/~jwkdwgmy/client-project-management/” style=”info” color=”red” window=”yes” bg_color=”00000000″]Client Projects[/button]

Posted on

Project Failure Warning Signs

failing project recoveryWe all know how projects should be initiated. After a thorough planning process in which the  crystal clear scope is laid out and everyone agrees on a sound plan, all team members go to work and “just” execute the plan. So much for the theory. Enterprise Project Management Main Page

In reality, however, project failure rates are high. Projects often do not get initiated the right way and you must launch a recovery of a failing project. Perhaps someone else did the planning and you are assigned to take over the execution phase. Or someone else didn’t get the project done right and you have been asked to fix it. In any case, I hope that this post will get you on your way to successfully manage whatever someone throws at you. Project Failure

The first and most important task for you in taking over an already planned or already running project is to understand the project’s scope. If you don’t know where the ship should go, you won’t be able to steer it. This is especially important when you are asked to take over a project. You must understand the scope and if you can’t find a solid scope statement, remember that it is never to late to compile one. If you don’t understand the scope, chances are you are not alone. Without a solid scope, you will have a hard time finishing what someone else started. I found it most useful to actually draw a picture that shows what is and what is not in the scope. Make sure that at least you and the sponsor are crystal clear about what you have to deliver. Project Rescue

Second, try to find the project charter and the stakeholder register. The project charter should tell you why you do what you do and what your boundaries are as a project manager. This is very important because you will have to maneuver your project around many obstacles and it is always good to know what the boundaries are. The stakeholder register is important because it lets you get in touch with the people who are most important to the project.

Third, introduce yourself to the major stakeholders and the project team. Make sure they have the same understanding of the project scope that you have. Get the project team together and for an update on the current status. This is also a good time to go over the project plan with the team. You might wonder why you should go over the project plan so late in the game. Well if you know the scope, it will be easier for you to spot weaknesses in the plan, especially if you go over the plan with the team.

Last but not least, if you identify a major weakness, you should address it. You don’t have to re-invent the wheel, but you should point out what want to do differently. Project Catastrophes

So here is the bottom line: don’t be shy to take up the challenge of rescuing a failing project. However, I urge you to start with the scope. Your job as the project manager is to keep the big picture in mind. If you have to take over a project to turn it around, you will find that most often the project failed because of scope creep or other scope related issues. Tackle the scope first, all other things will fall into place.