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.
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.