Having provided a high-level comparison of waterfall and agile methodologies (or frameworks) in my previous article, I will now begin to analyze core areas where misconceptions arise and create problems in an environment that has been declared agile.
A failed conversion from waterfall to agile
The term “requirements” means many things to many people, and I’ve often found that even in a waterfall environment there can be confusion. I once worked in a company that had a robust business development team whose job was to analyze trends, get ahead of the industry direction, and discover new business opportunities. This team flew around the country to meet with current customers and prospects alike, talking to customers about their needs, frustrations, and visions, and then capturing them in a series of business documents such as a business cases, RFPs, and SOWs before the project was approved and they were converted by the PMO into project documentation.
Cultivate the following five attributes and your résumé should receive positive responses from prospective employers looking for the telltale clues of a strong, professionally mature project manager.
Five Often Overlooked Skills Needed to Excel in Project Management:
I think most charters do a better job at sanctioning the work than they do at making clear the authority level of the project manager. I confirm this on a regular basis with project managers working on chartered project who are expected to get project work
Getting the Most from Your Project Staff
Part 2 of a 3 Part Series
As a Project Manager you are tasked with getting work done through others. It may seem simple, after all these individuals are assigned to the project team and just need to do their job. But this is not reality.
What is reality is that project resources are often assigned work beyond your project and may even be involved in other projects. It is typical in the popular matrix project organization that team members do not report directly to the project manager, but rather a functional manager. This makes it even more important that the project manager have the skills to get work accomplished through others. Even the most experienced project managers continually report this as one of their top challenges.
In this three part series you will learn techniques that will maximize your ability to get the most from those individuals assigned to your project. The strategies presented will provide a solid approach that can be used immediately with your team.
Almost every company accepts the need to manage project benefits, but very few actually do it!
Earlier this year, I started a discussion and poll on the topic of why benefits management is so hard to do. The response was intense, with over eighty-two PMO managers, consultants and professionals related to the topic. This article summarizes and comments on these responses and draws some conclusions.
The poll asked respondents to select one of five causes why benefits management is so hard to do. The results of the poll follow. This article will be structured around these five potential causes and, of course, as one respondent suggested, all of the above may be the winner.
Although these specialty software solutions are smaller in size and scope, they do require a relative measure of project management consideration. Many times I have seen dismissive or optimistic project managers assume that because a solution is smaller in size and scope, one can take a very relaxed approach to the implementation life cycle. In fact, greater care than what is found on ERP implementations needs to be emphasized in certain areas of the project.
IntroductionOver the course of my career in software development, I have had the fortune of working in a wide variety of companies employing radically different approaches to the software development life-cycle (SDLC). Some strictly stuck to traditional Water Fall. Others called themselves "agile" but never actually bothered to adopt any agile framework, and were thus a blend of Water Fall and Agile—and all too often, not a successful blend either. Another strictly adopted a true agile methodology and decided that there was no need for a PMO since, as they put it, "we're SCRUM." Other companies used the same Scrum methodology but saw the value of having a PMO as well.
As I have closely followed discussions on Project Times (and other blog sites), I have noticed some discussions around Project Management methodologies that are fine in theory, but often seem divorced from real-world applications. You can often find arguments prefaced by statements such as "good project managers do X," or "the PMBOK methods require Y," or even "any experienced Scrum Master knows..."
I don't doubt it. The relentless battle cry to reduce waste and increase productivity has many project managers feeling like they are expected to build a bridge over the Mississippi River with one team member and a box of toothpicks. By tomorrow.
How much of this challenge is exacerbated by the lack of clear organizational priorities to guide how those precious resources are allocated?
One of the critical factors for project success is having a well-developed project plan. This article provides a 10-step approach to creating the project plan, not only showing how it provides a roadmap for project managers to follow, but also exploring why it is the project manager's premier communications and control tool throughout the project.
Step 1: Explain the project plan to key stakeholders and discuss its key components. One of the most misunderstood terms in project management, the project plan is a set of living documents that can be expected to change over the life of the project. Like a roadmap, it provides the direction for the project. And like the traveler, the project manager needs to set the course for the project, which in project management terms means creating the project plan. Just as a driver may encounter road construction or new routes to the final destination, the project manager may need to correct the project course as well.