Upfront Project Management Involvement
Posted by Brad Egeland
I recently had the pleasant opportunity of having a discussion with several members of an organization who seem to be ‘getting it.’ And by getting it, they seem to understand that Sales has their definite purpose, but before everything is locked in place on an engagement, that Sales team really needs involvement from the delivery team to make sure this is all going to work. Sounds logical, right? Well, many organizations are making it a lot harder than it should be. I apologize if this sounds old to you since I’ve written about it before…but I hope you’ll stick with me and read on…
Sales is great, but….
Sales is obviously a key organization in any professional services company. Without sales, we’d have no projects to work on. However, many companies that I’ve worked with or for seem to think that there is a distinct line between Sales and the delivery part of the organization. You often hear, “Here, Sales closed this deal and now it’s your project – link up with Sales and get the handoff information so you can start the project.” Those words make me cringe. There are probably a long list of things that are wrong with that process, but I can give you three major ones right now:
#1 – Sales is primarily concerned with the sale
Sales is worried about making sales. After all, it is their job. And their salaries, commissions, and bonuses depend on it. If they didn’t make the sales, the rest of us in the professional services organization would have nothing to deliver on.
What’s wrong with this? Nothing really – but as I’ll discuss in #2 below, they aren’t Delivery and therefore are not in tune with what Delivery needs out of the Sales process.
CEOs and the Changing Technology Around Them
Posted by Brad Egeland
Today’s CEO is challenged in a way that no CEOs were challenged before. Technology is changing and too fast for even the CIO of an organization to keep up with, let alone the CEO. Yet those critical decisions of company direction, how and where to grow the business, and what new technology to incorporate ultimately falls in the lap of the CEO.
How does one person do it? The right answer is, they don’t. It’s critical for the CEO to be surrounded by the right people to help him make good decisions for the company. Just like an employee has to answer to their manager or management team, likewise the CEO is subject to the guidance, oversight, and decision-making of his board of directors. Everyone is accountable to someone.
Making tough decisions
The CEO must make sound decisions on what new market niches to attack. He’ll look to his marketing team and expect the right decisions will be made based on their analysis of the industry, but ultimately he’s responsible.
The CEO must make sound technology decisions. He’ll look to the CIO or IT Director for their input on what direction to take, what technology to acquire, who to partner with, etc., but ultimately it’s his decision and the target is on his head.
Ten Characteristics of Successful Project Teams – Part 1
Posted by Brad Egeland
Have you ever been a member of a high-performing, smoothly running team? If you have been, it’s an experience that you are not likely to forget. On this type of team there is usually a strong trust bond, people work cooperatively together to reach the common project goals, and often the project is even more successful than the project manager and customer could have imagined. These types of teams generally have some key characteristics in common that help make them the effective, high-performing teams that they are. In this series, we’ll examine ten key characteristics of these types of teams.
These ten main characteristics of successful project teams are:
- Clearly defined goals
- Clearly defined roles
- Open and clear communication
- Effective decision making
- Balanced participation
- Valued diversity
- Managed conflict
- Positive atmosphere
- Cooperative relationships
- Participative leadership
For Part 1 of this series, we’ll examine the first two in more detail: clearly defined goals and clearly defined roles.
Final Thoughts on Requirement Prioritization
Posted by Brad Egeland
Your first priority in the requirement prioritization may be selling the stakeholders on the concept of prioritizing requirements before design start. This isn’t an easy task. As we discussed, a customer stakeholder is likely to react with the notion that you’re actually trying to eliminate requirements. You have to convince them that this is not the case.
Once the stakeholders agree to prioritizing requirements, you will guide the stakeholders through the prioritization process. Then, you will incorporate the results into the project or the product development schedules and budgets. You must enforce the priorities throughout the development process.
As development progresses, you will identify situations that trigger use of the priorities. These situations may include: impending resource shortages, changes in external constraints or expectations, and conflicts. You must ensure that the priorities rule the outcome.
Requirement prioritization early in development helps a manager control project risk and change. Knowing requirement priorities focuses a product or project development team and guides intelligent choices for phasing in product features over time. It prevents the “bailing” that so often occurs just before delivery, in which partially implemented requirements are thrown overboard in a frantic effort to save dwindling resources for finishing the critical components. Above all, it’s one more communication channel between customers and developers.
Should Requirements be Prioritized?
Posted by Brad EgelandBefore starting design on a project, it may be a good idea to prioritize your requirements. Why? Because grouping requirements together by relative importance can help you down the road with the customer in terms of flexibility in tradeoffs, design, and implementation should scope start to creep … as it usually does.
You’ll need the customer onboard to perform any requirements prioritization and that’s not an easy thing to do, but enlisting the customer in this effort and doing it at the beginning of the project before you actually spend resources on project requirements can give you the best flexibility.
Making a case for prioritization
If you postpone requirement prioritization and you end up facing a resource shortage, you may find yourself throwing away work already performed on lower priority requirements in a panic effort to focus on and finish the truly important ones. By the time a crisis like that comes in to play, it may be too late to fix it with prioritization. The portion of the project or product developed with the lower priority requirements may be too tightly intertwined with the portion implementing higher priority requirements to do anything about it. Dropping some requirements late in the development process may require major and expensive rework on the project and end solution.
Knowing requirement priorities early can help avoid the late-stage implementation train wreck. Prioritizing your requirements before design starts provides options to manage requirement additions and risk, enables delivery of a useful product in spite of changes in schedule and resource allocations, and guides architecting and design tradeoffs.
