Succeeding in today’s business environment will require a well-thought-out and fundamentally different strategy than it’s been in many years. So, what are the keys to success for the next decade? And who is best equipped to understand and leverage these advantages?
Receiving project schedules is nothing new to us. We get them all the time. They can be for a project we are dependent on, have a casual interest in, or are a part of our organizational portfolio of projects. We often take them at face value but should we?
Many organisations choose to run groups of related projects as a portfolio, aiming to create synergies and savings by managing them together. Risk is one of the most important aspects that must be managed at portfolio level.
While a correctly developed project schedule is a thing of beauty, a poorly created one can be a source of frustration to the project team and risk to the overall project success. Developing a schedule before spending time to decompose the scope of a project is likely the primary sin of most poor planners, but it is closely followed by the incorrect usage of schedule dependencies, constraints & deadlines.
For years now I have been going around as a certified agile Scrum Master thinking I was being humorous by introducing the term "Wagile" to those customers who thought they were agile but had fallen into a variation of agile, slipping from into waterfall.
The risk process produces large amounts of data that are needed to support analysis, reporting, decision-making and action. Tools can help us to manage these data efficiently. But there are many alternative risk tools, so how can you choose the right one for your needs?
In every single successful project I’ve ever been associated with there was a project structure which ultimately put responsibility and accountability for the project on a single project manager. Depending on the size of the project the project manager may have a number of project managers working with her on a project but at the end of the day there was one person ultimately accountable for delivery.
In today’s new normal business environment, sales are lackluster, cash is tight and material prices are squeezing margins. Thus, those projects which will increase sales, reduce costs and/or improve customer service levels/ loyalty are quickly becoming #1 priority within the organization.
More often than not software is about products, be it boxed software systems sold to businesses and individual users, platforms and integrated suites delivered to enterprises or internal tools used by various business units. And while most of the users and business stakeholders usually deal with software products, development teams mostly work on software projects.
User stories are great at capturing product functionality from the perspective of a user or customer: Each user story describes a piece of product functionality, for instance, “As an application provider, I want to register with the application centre so that I can use its services.” By focusing on a distinct area of functionality, the story allows the team to understand, implement, and test the requirement.
Most Popular Articles
Sponsored Articles
