We work hard on our projects to ensure all our goals and stakeholders’ needs are met. Yet, sometimes when we reach the end of the road, we find some of our goals have not been achieved and one or more key stakeholders are not happy with the outcome. How do we avoid that situation?
Project management fads and fashions like entrepreneurial PM, Agile PM, earned value, and critical chain PM, come and go. Often they get folded into the overall knowledge base as skillful techniques. What they all have in common is the ability to wake us up a bit, focus our attention on our process and get us out of a rut.
Managing with a Business Architect’s Mindset: Redefining the classic Project Manager’s role to deliver substantial business value
This is the second part of a series on how the project management profession must evolve to remain a vital part of an organization’s success and deliver business value. The first part made the case that managing the triple constraint (time, cost and scope) is not enough anymore. To excel, project managers must go beyond the current project management practices and ensure that their projects bring full business alignment. This paper will build on that point of view and discuss what it means to manage a project with a business architect’s mindset.
Last month’s article presented ways in which the first four stages of Dr. Kotter’s eight-stage change process model can be applied when attempting to institutionalize agile approaches, and this sequel covers the remaining steps.
If you’ve used some of the tips I had provided in the previous article, you should have key stakeholders embracing the immediate need for this transformation and have a well-defined end state vision. In addition, you’ll have defined a strategic plan to achieve that vision, and have effectively and frequently communicated the rationale for moving to agile methods and what the end state will look like.
I don’t know about your experiences, but when I’m managing projects I rarely have the luxury of running just one project at a time. Even if I have a large engagement on my plate, I usually have at least a couple of other projects going on concurrently. That said, it’s easy – when issues come up on any project – to let that project or one of the other quieter projects get a little off track or a little out of control. And, if the project with issues or high priorities goes out of control then the damage can be large, the magnifying glass on you can be huge, and the customer satisfaction can be of major importance.
Before becoming a full-time consulting engineer, I had never encountered a project that took more than a few months. Besides my master’s thesis, all my previous educational and professional work had involved narrow scopes, short timeframes, well-defined processes, few alternatives, and more or less predictable outcomes.
In January we wrote an article like we do every year about the upcoming trends in business analysis and project management. In this article we want to discuss what these trends mean for practitioners of business analysis. Below are the seven trends we discussed in last month’s article and a short description of each.
As we kick off the New Year, it is imperative to revitalize our projects. After working with countless manufacturers and distributors to elevate business performance, I’ve found that projects are the lifeblood of most organizations as their success or failure impacts customers, profit/ loss and or cash flow in almost every client. Thus, making sure there is significant emphasis on their success should be a top priority for success.
You just never know what is going to happen in your business life. Recently I had to work like crazy to get a bunch of deadlines completed to free my schedule so I could take an unexpected trip, half way across this wonderful country of ours, Canada.
In a recent recording of our Meta-Cast, Josh and I went through a couple of questions from the audience. One of the questions surrounded what to measure for individual developers. To be honest, I was taken aback by the question.
You see, I’ve been preaching for years that when you move to agile metrics, you want to do three things:
(One) Move from individual team member metrics to a more holistic, whole-team view.
Project Manager (PM) is no doubt one of the most stressful jobs out there as the PM is directly responsible and accountable for the success or failure of a project. Some PMs believed that they can handle and cope with the high level of stress but there are some who are ignoring or refuse to recognize that they are under stress. The experience of stress is not only impacting the cognitive and behavioral performance, it can also have a negative impact on your personal health, wellbeing, and family life. You might not able to change the amount of stress you have on a daily basis, but you can change how you deal with it. It is important to manage the stress before it becomes more and more difficult to handle and manage.
The Yerkes-Dodson Curve
In my role I set strategy, recruit, oversee development, handle the budgets, deal with staff problems, chair meetings, take minutes and make the coffee. In fact, that list doesn’t even begin to touch on the variety of tasks I find myself doing every day as a CEO. It’s just as well that I don’t have a job description because if I did it would be very, very long.
Ask to see a copy of a job description for the project managers in your team and you’ll probably be handed a dusty document. Dusty? Of course. No one in project management does what it says on their job description any longer. If we all stuck to that then I doubt we’d ever complete any projects at all.
In my last post, Guiding Community Change, we looked at how a community based initiative went from being a source of distrust and discord to a shining example of collective and collaborative community action. That fundamental change in direction delivered a community asset that will be enjoyed by present and future generations for years to come.
I just read an article written by a consultant for PMs about avoiding project mishaps. How interesting and typical that a project management consultant would suggest the answer is to bring in more consultants and project managers to save the day. Yet, some of the concepts were right on track – too few resources, lack of skills, lack of focus and of course everything is high priority.
Projects don’t fail because teams lack the skill or the will to succeed. They fail because they fall into the Void – the space where the org chart fails to establish clear owners and aligned incentives. In the Void, things slip through the cracks, conflicts don’t get resolved and progress screeches to a halt.
Who doesn't want to perform optimally?
Performance is action to accomplish a project, task or function. It may relate to painting, dance, software development, accounting, cooking, or living effectively in a relationship. High functioning people want to optimize their performance to make sure they sustainably meet ever-changing success criteria, like satisfying customers, staying on budget, etc., while adjusting for current conditions and balancing thoroughness and efficiency so as to not overtax the resources at hand.
Kicking off a new project can be an interesting and rewarding experience. It can also be a nightmare. The difference between the two is often determined by just a little proper forethought and planning in advance of the initial customer contact and kickoff preparation process. The kickoff process is never simple and easy – it does require a fair amount of planning and effort. However, a project that is kicked off well will properly set customer expectations, possibly even senior management expectations, and get the critical project planning process that happens next off to the best start possible. All of these are key ingredients of success on any project.
Judging by its use in the popular media, the term "narrative" explains, well, just about everything. Google “narrative” and among the 21,900,000 results are references to the Israeli-Palestinian conflict, Mitt Romney’s lackluster presidential campaign, the doping scandal in Major League Baseball, and the impact of Lindsay Lohan's personal life on her most recent movie. Buried among these results are a significant number of hits that link project management and narrativity. For the most part, they propose using narrative as a tool to structure progress reporting or to shape change management processes. What they don’t do - and what is the focus of this discussion - is to compare this new concept of narrative with its more traditional definition, involving concepts like plot, character, and author, in order to suggest how it might be fruitfully applied to project management and the role of the project manager.
Each year we like to reflect on what’s happened in the business analysis, project management, and Agile professions and make our predictions for the upcoming year.
To summarize the trends we saw in 2014:
- Continued excitement about Agile projects with more informal communications and documentation and use of modeling tools to get from high-level user stories to detail needed to estimate and build them
- Focus on Design
- Cloud computing
- Greater interest in business analysis by project managers.
Below are the seven new trends we see in the Project Management and Business Analysis fields for 2015.
Your career goal wasn’t to be a Project Manager (PM). You haven’t read the 589-page tome, Project Management Body of Knowledge, and you don’t include “PMP” among your professional credentials. Yet you find yourself making schedules, dealing with budgets, and reporting success metrics to stakeholders. What’s going on?
You’re not the first person to have fallen into the role of “accidental project manager.” As hierarchy is becoming more horizontal and org charts have more dotted lines than solid lines, the administration of work is no longer reserved for trained specialists. For all intents and purposes, work is comprised of projects, and projects need to be managed—by someone.
In the IT world especially, accidental project managers fall into two groups: those who are managing projects but don’t think of themselves as PMs (i.e., pretty much everyone), and those who have fallen into a more official PM role because of their natural aptitude or inclinations.
With ever new year comes well intentioned change resolutions so perhaps your company has agile transformation as a key resolution. While agile is no longer a fad, there continue to be organizations which struggle with transitioning from traditional project management approaches. This can unfortunately result in a “been there, done that, never again!” outcome.
I’m neither an agile fanatic nor a Luddite.
I’ve always encouraged using or adapting the most appropriate approach, practices and tools given the context of a project and the culture within the organization and team. Having witnessed the tangible benefits which can be realized when an organization effectively embraces agile approaches, I am an advocate who would like to see fewer failures.
As we think about the New Year, we should review our projects. Since projects are the lifeblood of most organizations (as their success or failure impacts customers, profit/ loss and or cash flow in almost every client), why wouldn’t we take this opportunity to make sure we are focusing on the “right” projects to move our organizations forward rapidly? In essence, take stock of projects.
One area that all of my clients have in common is that they have too many projects going at the same time – without exception. Since the marketplace is changing rapidly, it feels as though everyone is playing catch-up while simultaneously trying to grow the business and manage costs. Thus, to be successful, focus is required. How should we prioritize projects? I’ve found a few simple guidelines to work: 1) Fit with strategy. 2) Impact 3) Urgency 4) Change
I’m wondering if you think this post will be about the Scaled Agile Framework or SAFe? Well, it’s not. Before there was SAFe, there was good old-fashioned “safety” from an agile team perspective. And that’s where I want to go in this piece. So just a warning that no scaling will be discussed.
I often advise teams and organizations that are contemplating “going Agile” to consider safety as a factor when running their retrospectives. I share the “Galen-rule” around not inviting or having “managers” in the teams’ retrospective.
This usually gets the attention of the managers in the room and we have a lively debate around why I’m recommending this. They normally get quite defensive and start explaining how effective they’ve been in driving results from the retrospectives. How the team produces plans and action logs from each retrospective and how they hold each other accountable to those results.