CEOs and the Changing Technology Around Them

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.

Read more »

Ten Characteristics of Successful Project Teams – Part 1

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.

Read more »

Final Thoughts on Requirement Prioritization

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.

Read more »

Should Requirements be Prioritized?

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

Read more »

Project Transition to Production Support

As part of methodologies I’ve previously discussed, the final phase is something that I call the Post-Deployment phase.  Once the project is implemented – or deployed – the delivery team, the customer, and the project moves on into the Post-Deployment Phase.

The Post-Deployment Phase is the period of time when the delivery team remains as intact as possible to support the customer and the deployed solution before a final and formal transition to technical, or production support.  This post-deployment period is usually somewhere between 30 and 90 days in length (30 is more likely) and that time period is set either during the sales process (and becomes part of the statement of work) or during the kickoff session.

Upon satisfaction of the post-deployment timeframe, support formally moves over to the company’s techical or production support team.  The template I am unveiling here is a formal document to record that transition process, allowing the project delivery team to identify specific things about the project that the production support team will need to know.  While reviewing this document, keep in mind that there are really three very key pieces of information in here that the support team will need to know the most about:

• Schedule
• Communication
• Change Control Process

PROJECT TRANSITION TO PRODUCTION SUPPORT

[Save file name as: client name PRODUCTION SUPPORT yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work performed.

SCOPE

Describe the deliverables/actions to be supported. Provide additional documentation as appropriate.

SCHEDULE

Describe the timing for support activities to be performed. Provide additional documentation as appropriate.

COMMUNICATION

Describe all required communication needs for support – What to communicate, to whom, in what format, and when. Provide additional documentation as appropriate.

QUALITY ASSURANCE

Describe the Q/A processes to be performed. Provide additional documentation as appropriate.

COST

Describe the support costs estimated by the project. Provide additional documentation as appropriate.

CHANGE CONTROL PROCESS

Describe how changes to the Production Support process will be addressed. Provide additional documentation as appropriate.