The risk we take in swearing allegiance to a specific approach is that following the approach often becomes more important than achieving the goal of the project. Let’s explore the merits of using the best of different approaches—and how marrying them into a hybrid model impacts the way projects are planned and managed.
As hybrid projects become more common, what has to change among team members, and how do we manage that change? Do we have to minimize these disruption scenarios, or can we create an environment where teams are more comfortable with the shifts?
If you have not run a hybrid project leveraging agile and waterfall methodologies, you are in for a great learning experience. Let’s put the two distinctively different approaches into a broad and high-level context…
ProjectManagement.com is excited to bring you the 9th edition of its annual virtual conference and exhibition! It's your opportunity to learn, network, earn more than 6 PDUs and gain valuable knowledge—all from the comfort of your home or office! You can view PMXPO 2016 on demand through July 28 for six sessions full of informed project management viewpoints from leading industry experts--led by our keynote from Robbie Bach, innovation expert and former Chief Xbox Officer.
Continuing to develop a failing project is a big challenge. Improving the environment and culture to ensure successful delivery requires integrating the bottom-up approach from a small task level with a top-down orientation of strategic management. Learn how to diagnose failure and implement useful techniques.
Project managers must ensure that projects are aligned with business strategy and value creation for their company and its shareholders. The author demonstrates the importance of the bridge between the business and project worlds, even when there is not a clear link between their objectives. But one objective always remains the same: to create economic value.
Intelligent technologies that simulate human intelligence are changing the way we work. These advances in technology have the potential of replacing certain types of jobs and how we adapt to these cha ...
By Conrado Morlan
The number of credentials offered by professional associations, hardware and software vendors and other organizations has grown sharply in the last decade. So have the number of c ...
Are you still blaming users for new requirements? Why is this all happening? Is it because of the lack of discipline among requirements holders, who just keep on asking for different things—often late in our projects—throwing a monkey wrench into our schedules and budgets?
The best agile software teams communicate well, push hard to meet deadlines, support each other when struggling with issues, and go above and beyond to maintain quality. The key element is trustworthiness. In this article, the writer provides a self-assessment tool that will allow you and your team members to assess and demonstrate trustworthiness over time.
Question: We have switched to agile practices and, if I do say so myself, I think we are doing an awesome job. However, even though we are carefully creating backlog lists and writing user stories, more often than not our end product or service still does not meet the expectations of our internal and external customers. Has something been left out of what we were taught?
Agile does provide a way to use non-functional requirements in its methodology, but often it is overlooked or not stressed when new teams are preparing their first few projects. Make a point to add them into your new process.
The reason agile projects are completed so much faster and provide so much more value is that with the Scrum practice methodology, it is no longer necessary to consider vague things like non-functional requirements. If they aren’t going to function anyway, why bother with them.
User stories are only written if there is a need for outside personas to be created to represent users. Non-functional requirements are the ones assigned to those personas who would not be interested in your product or service, and therefore can be excluded from consideration.
Many projects have both functional and non-functional requirements that impact the outcome of the project. That is why only traditional processes should be used. Agile processes work only on software projects, and then only when there is an absence of non-functional requirements to be considered.