While you might not realize it, you could be exhibiting the symptoms of a project manager who follows McGregor’s Theory X management philosophy from the very start of your projects!
Use case models have been around for decades. Long after Information Engineering was all the rage and through object-oriented analysis and design they hung around. They threatened to disappear when Agile methods gained popularity, but here they are--discussed, dissected, and the subject of many blogs. Aren’t they “old school” and not needed in today’s Agile world?
There is a buzz about agile project management being the “in” trend. There are workshops, seminars and lots of conversation about agile. However, what does agile mean? According to Webster’s dictionary, it is the ability to think quickly or a quick and well-coordinated movement. I see it as meaning flexible. In the project management world, there are countless discussions geared towards agile. But is it really just common sense?
If we don’t know our history, we are doomed to repeat it. Knowing an organization’s past failures and successes are keys to smooth project management in the future. Unrealistic expectations are avoidable, and colossal barriers to project success. So, how do we manage these expectations from the very beginning of a project before it’s too late?
It’s difficult to produce your best results when you’re under attack from your boss. Unfortunately, management applied duress, intimidation, pressure, bullying, and browbeating of individuals and teams is a too frequent occurrence. And it is incredibly costly in both the short and long term, in lost productivity, poor morale, staff and customer turnover, and bottom line impact.
Internal promotion is a sustainable method of maintaining company culture and engagement, but spotting an aspiring leader whose conduct and work records indicate potential success in a management position can be difficult.
What you don't say and how long it takes you to say what you do say sends a message. This article focuses on responsiveness, particularly to emails and voice messages, and how it affects communication and project success.
Mindfulness has received significant coverage as a good practice for improving one’s interactions with others on both a personal and business front. It is rare to find an article in the Harvard Business Review on leadership, conflict resolution or negotiation that doesn’t touch on the concept.
We know how difficult it is to deliver projects successfully within an organization. Imagine the challenges involved in managing hundreds of concurrent projects in developing countries and communities around the world. That’s exactly what the Canadian Executive Service Organization (CESO) does and has been doing successfully for almost 50 years in Asia, Africa and South America and among Aboriginal communities across Canada.
In my last post, we explored a situation where a Product Owner had a long-term challenge with their performance that was weighing their team down.
Have you ever watched a child learning to ride a bike? Who (or rather what) gets the blame when things don’t go the way the child wants? The bike! The child might even argue that it’s a stupid bike and it’s impossible to ride.
Over the course of my career, I have always been intrigued by leaders who promote a specific methodology or tool or process as THE RIGHT WAY to deliver solutions. They dispense mandates and proclamations to promote their all-or-nothing, purist approach to methodology. Typically it is because it worked in the past for them, and once it fails to deliver results onto a new one.
As project manager, you more effective if you act as a facilitator rather than a command and control manager, even if you are in the minority of project managers that have clear authority over the resources working on your projects.
In today's challenging business conditions, corporate executives struggle to keep businesses running smoothly while effectively leading the changes in the corporate business environment. In many cases, these changes are managed in the form of programs or projects where executives play the role of sponsor.
Collaboration has come into vogue. In my experience working with clients ranging in size from $4 million to multi-billion dollar enterprises across a multitude of industries, spanning building products to aerospace to consumer products, the more collaboration is valued, the better the company has performed over the long-term. Certainly, project results are directly tied to collaboration as the vast majority of projects are cross-functional and cross-company in nature.
If you have a project-based business, you already know that many things can go wrong between you and the successful completion of a project. From budget to bureaucracy, anything can suddenly become a viable threat to your project. However, the most detrimental of them all is not knowing when you will finally finish the project successfully.
This article is the second in a series on requirements modeling with the emphasis on why PMs should care about modeling requirements. Last month we spoke generally about models, the benefits of modeling requirements, and introduced the relationship between the iterative nature of eliciting requirements and modeling them. This article discusses the concept of concurrent requirements modeling, a structure that helps us elicit the detail needed for a complete set of requirements.
For managers, time is a scarce commodity. Actually, it’s equally scarce for everyone, but I start off this way to show that I know how tough it is to be a manager. When I meet managers of various kinds - CEOs, division managers, middle managers, indeed all sorts of managers - I take their lack of time into account and let them know that there’s only one thing they need to do to develop a culture of continuous improvement. This is what I tell them:
Technological complexities often pose significant challenges to project staff. That’s especially true when a number of companies are involved and the technologies run the gamut from hardware subsystems, system and application software and communications infrastructure. In these cases, the difference between success and failure is often a function of detailed minutiae. Correctly addressed and everybody’s happy. One small item overlooked and there’s hell to pay.
Bad requirements or no requirements are definitely not the best way to start any technical project. But most project managers will tell you that you aren’t likely to get your best requirements from your project customer – no matter how certain they may be that they have thoroughly documented everything for you. The problem is, some project customers aren’t even certain they know the right problem or need that the project is going to be addressing for them. In those cases – and that’s often from my experiences – there is no way a project client could have good, detailed requirements waiting for you. They don’t even know the real problem yet…they’ve likely only documented a symptom.
I was talking to a fellow coach the other day and she was venting a bit about one of her teams and their Product Owner.
Bob, she said, I have an outstanding agile team. We’ve been working within our product organization for nearly two years. In that time, we’ve delivered an application upgrade that everyone has viewed as simply fantastic. Now we’re onto a building a critical piece of new system functionality for them—so we’ve earned everyone’s confidence in our abilities.
We often get asked how project managers (PMs) justify allowing enough time to model requirements on their projects. These PMs complain that although they agree that requirements modeling has huge benefits, they have a hard time justifying the amount of time it takes. This article opens a series on requirements modeling with the emphasis on why PMs should care about modeling requirements. Each article looks at a single model, the benefits of that model to the project, the questions PMs need to ask related to that model, and how much the PM needs to understand in order to manage the requirements modeling activities.