Project Management

A long, long time ago in a land far, far away…. a project delivery team was busily spending their days delivering projects. They were tasked with delivering change projects and often these included software delivery. This team consisted of people with a variety of skillsets, personalities and experiences. Some of them were project managers, some were analysis and some were developers. Others were software testers and others were business experts and non-project people.

Since 2009 we have enjoyed reflecting on what’s happened the previous year on projects and making predictions for the upcoming year. Here are some of the recent trends we have discussed: agile successes and challenges, recognize the importance of roles that help maximize value, Scaling Agile, Certification trends in business analysis, etc...

Here are the seven industry trends that we have chosen for 2018.

Estimating is one of the most controversial subjects in project management. There are some people who have turned the subject into a cryptic science involving esoteric techniques. Estimating is simply the process used to determine the amount of effort and cost required to implement a project, in part or in full. It is important to acknowledge that...

An effective product roadmap is a must-have for any successful software development project. A roadmap helps the product manager define the trajectory of a product, communicate progress to stakeholders, visualize goals and justify changes to budget. Product roadmaps are where both strategy and tactics combine to help teams build better products.

The paradigm shift towards agile and lean product development has brought collaboration between large cross-functional team in the spotlight. The existing literature is already mature explaining clearly how benefits can be reaped fast by executing a clean transition to agile delivery by enhancing the performance of the new cross-functional teams. However, in parallel, the time spent in endless meetings by product owners, business analysts, engineers, product managers and many others involved in the product creation, has grown exponentially. This leaves key product people with little or no time to do the critical activities they are employed for.

Watching the speed by which Information Technology (I.T.) has changed over the last forty years has been amazing. Hardly a day goes by without some new twist or invention. In particular, my interest is in how I.T. can be applied to support the systems needed to operate a business, such as for manufacturing, inventory, order processing, customer service, accounting, human resources, and much more. I have seen a lot during the last four decades, perhaps too much.

Through the use of contract terms and conditions, this article provides insight on managing risk on outsourced projects beyond just transferring work to a contractor. Training courses on risk management typically cover transferring risk at a high level, but that is just a start. Read this article for the follow-ups on managing risk via contract terms and conditions.

The context diagram and the use case diagram are two useful techniques for representing scope. This article describes two other methods for documenting scope: feature levels and system events.

A bid is like a product that, once designed, the team must be able to deliver it. This delivery includes manufacturing the product, testing it, preparing the marketing for the product launch and finally launch it.  We propose a staged approach that replace guessing a number with qualitative investigation. The model suggested, distilled from experience, shows how estimates are transformed into effort and, ultimately, into a coherent story with a price tag attached.

Every software team talks about project scope and team members often complain about unending scope creep. Unfortunately, the software industry lacks uniform definitions of these terms, and the requirements literature is short on clear guidance regarding how to even represent scope. I confront scope head-on in this series of three articles...

It is common for projects to be initiated based on blueprints. However, a blueprint is just a guide to the future state. Its intended purpose is to guide the subsequent analysis and design activities. It does not answer all the questions. The details of what, how, and why are left to requirements analysis.

Being required to produce documents that create massive information bloat and don’t add value is frustrating as it slow projects down and creates additional project cost that isn’t needed. It’s a headache for Project Manager, Business Analyst and everyone on the team. What we need is the smallest set of information that can be verified and validated quickly that directly ensures the highest quality outcome of the project. 

If you are a Scrum Master of an agile team, your prime purpose is to help the software development team remove obstacles that are impeding progress. The best practice approach in succeeding at this is to assume the role of a neutral facilitator. That is, the Scrum Master guides the team through a process for solving situations themselves rather than the Scrum Master proposing a solution. This article provides two workshop scenario exercises (an internal team conflict and a team conflict with the product owner) that help the Scrum Master practice the neutral facilitator role.

...why blame the success or failure of the project primarily on requirements? If the business analyst is not in charge of the monitoring and controlling of the project, why pass the blame on. If a decision to apply one form of methodology over the other does not rest with the BA, is it not valid to review the stewardship and question the effectiveness of the stewardship?

The 3 Amigos (sometimes referred to as a “Specification Workshop”) is a meeting where the Business Analyst presents requirements and test scenarios (collectively called a “feature”) for review by a member of the development team and a member of the quality assurance team.