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.
Emotions are a fact of life. Everyone has them. However, not everyone manages them so well.
The master project manager or business analyst cultivates both the analytical skills of scheduling, estimating, budgeting, process mapping and controlling, and the behavioral skills required to manage relationships. Healthy relationships are the key to successful projects, effective communication is a key to healthy relationships, and well-managed emotions is a key to effective communication. Well managed emotions boil down to the ability to be responsive rather than reactive.
Choose your company or project … I'll even go out on a limb and say that it really doesn't matter the size or scope of the initiative … The story is always the same …
There is work to be done that is not fully understood by management, who wants it done yesterday.
The groups in the trenches performing the work are asked "when it will be done." This usually entails detailing plans, or in many cases simply communicating a "completion date."
As the recovery takes hold and businesses become more comfortable investing money, top project managers have become scarce. In order to grow the business, improve profitability and accelerate cash flow, projects are integral. Having the ideas is “easy” in comparison to executing those ideas. Solid project management will ensure these results occur. Thus, those companies who retain top project management top will thrive and leave the rest in the dust. What can be done to ensure you are in the driver’s seat?
Maybe all of your projects are going strong right now. But if you’re like me and you are overseeing 5-6 projects at a time and we know that there is a greater than 50% failure rate (to some degree) on technical projects, then it’s likely that at least one of your projects is struggling. What I want to cover here is ten positive ways that – with out a lot of effort – you can improve your project right now. Nothing earth shattering or difficult to implement, that’s what makes it so practical that you have no excuse but to implement some or all of these this week. Try it and see how it goes – then let me know – because none of these will hurt your project and all should help to some degree. And that’s all we’re looking for, some improvement to customer satisfaction, project visibility in your own organization, team ownership and accountability, resource management, and financial management improvement.
Often we want all the moving parts to connect together in our business. We want everything and everybody rowing in the same direction together. This is not always easy to accomplish.
In today’s competitive climate with global competition we need to break down internal barriers and align the strategic thinking and goals and objectives of our departments.
Organisations are increasingly experimenting with 'agile' approaches to software development – combining incremental and iterative ¬¬¬approaches in one. To manage the risk of this change, initial experiments are understandably small and focused¬¬, targeting relatively simple solutions with few integration points and co-located teams of five to seven people.
With few exceptions, gone are the days when a team would plan a business project to a low level of detail, secure approval from their customer on scope, schedule and cost baselines, and then not have to be concerned about anything changing over the project’s lifetime.
Doesn’t it seem like we can hardly go a day without reading about how missed requirements are leading to incredible amounts of wasted time, energy, and money on information technology projects? I have been inside enough projects to know that the statistics are most likely telling a realistic story about how projects get scoped, defined, and delivered, but that they are not necessarily giving a comprehensive account of the situation.
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.