Showing posts with label Scope. Show all posts
Showing posts with label Scope. Show all posts

July 25, 2019

Lasting Decisions

So it's a funny thing about decisions...

Decisions are supposed to represent the conclusion of a process involving the following steps:

- Research of the problem
- Decide on the scope
- Discover the requirements
- Determine viable alternatives
- Evaluate costs, benefits, and risks 
- Do some soul-searching
- And then resolve and commit on a way-ahead

While these steps are typically formalized in a work-setting, they may be done informally in our personal lives. 

But even after all this, we need to remain adaptive to changes in the environment that would cause us to reevaluate the decision and alter course. 
So a decision is a decision until we revisit the decision. 

The problem is that in some highly complex, unstable/turbulent environments, or ones where there are a lot of disagreements among stakeholders (such that there was perhaps not a consensus on the original decision to begin with) then "decisions" may be short-lived.

In this case, decisions may be half-baked, not even last until the ink is dried, and certainly not have a chance in hell to be executed on or seen through to determine whether they actually would've worked. 

In a way a decision that is so temporal is not even really a decision, but sticking your toe out to feel the temperature of the water, and any commitment of resources can and probably will be a complete throw-away.  

We've got to do the investment in the upfront work, really make a good data-driven (and inspired) decision, and give it an opportunity to blossom. 

Yes, we need to remain agile and change as we sincerely need to, but too much change and for the wrong reasons leads to going nowhere fast.  ;-)

(Source Photo: Andy Blumenthal)
Share/Save/Bookmark

June 2, 2018

Agile Doesn't Mean Endless

So Agile development is great for iteratively working closely with customers to develop and refine information systems that are useful to them and the organization.

But even in Agile, there is a beginning and an end to the sprint planning and project management.

Taking Agile to somehow mean endless in terms of adding more and more requirements or scope creep is not what is intended. 

Agile has to be bound by common sense somewhere between what is needed for a minimally viable product (MVP) and what is achievable with the designated resources, objective, and scope. 

Good project managers always have to be sound arbiters and be willing to ask the tough questions and determine if something is truly a requirement or simply a wish list item that is out of scope (but of course, could perhaps make it in for future enhancements).

We need to understand the difference between genuine customer service and irrational project exuberance. 

It's not a dangerous project bubble we want to create that can and will get busted, but rather a successful project that is delivered for our customers that help them do their jobs better, faster, and cheaper.  ;-)

(Source Photo: Andy Blumenthal)
Share/Save/Bookmark

December 13, 2017

Anything Is Possible

So you're all aware of the 3 legs of project management:

- Cost

- Schedule

- Scope

I remember learning the adage that if you change any one of these then there is an impact on the others. 

For example, if you "crash" the timeline on a project to finish more quickly, then you either need more money or you need to reduce the scope. 

Similarly, if you want to cut costs on the project then you may have to extend the timeline or scale back on the requirements. 

Recently, I heard someone says the following:
"We can do anything with enough time and resources."

And when I thought about this, it's true enough.

If you provide more money and time for a project then, of course, you can do more in terms of the scope of the project.

Pour enough bucks and time into something and conceptually, we really can do anything. 

Technically, we can do the proverbial "anything," but that's only if the politics and infighting don't get in the way of progress. ;-)

(Source Photo: Andy Blumenthal)
Share/Save/Bookmark

May 4, 2013

When Requirements Go Awry

You may have seen this before--it is a great comic strip on how requirements can go awry. 

When you look at how product or service requirements look from each person's vantage point, it is easy to see how they can be misunderstand, misinterpreted, or misrepresented. 

Getting clarity of the tire swing before we start can save a lot of wasted time, effort, and money on building contraptions that no one wanted or needs. 

Get the business and technical requirements spelled out in as much detail as possible from all parties; document, document, document; and have the customer approval and sign off on these. 

Build to specification, on time, and within budget and make sure it meets the operational mission needs and strategic vision of the organization. 

(Source Photo: here with attribution to tamingdata.com)
Share/Save/Bookmark

May 16, 2009

Executives, One Foot In and One Foot Out

The last thing any executive should be doing is getting caught up in the weeds of management. The executive needs to lead and define the organizational strategy and the management team needs to execute. The executive is the link between what needs to get done (stakeholders’ needs) for the stakeholders and getting it done (management execution) through the organization’s people, process, and technology.

How does the executive perform this linking role?

Not by looking myopically inside the organization, and not by jetting around the globe shaking hands and kissing babies. Peter Drucker said “ The chief executive officer (CEO) is the link between the Inside that is ‘the organization,’ and the Outside of society, economy, technology, markets, and customers. “

In Harvard Business Review, May 2009, A. G. Lafley the CEO of Proctor & Gamble see’s that the CEO’s job is to “link the external world with the internal organization.”

The executive is the bridge between inside and outside the organization. And by having one foot in each, he/she is able to cross the artificial boundaries and bring vital stakeholder requirements in and carry organizational value back out.

Lafley breaks down the CEO’s role into four key areas, which I would summarize as follows:

  • BUSINESS SCOPE: Determining “the business we are in” and not in.  No organization can be everything to everybody. We need to determine where we will compete and where we will withdraw. GE’s Jack Welsh used to insist on working only in those markets where GE could be either #1 or #2. Drucker’s view is that “performing people are allocated to opportunities rather than only to problems.”
  • STAKEHOLDER PRIORITIZATION: “Defining and interpreting the meaningful outside”–this is really about identifying who are our stakeholders and how do we prioritize them?
  • SETTING THE STRATEGY: Balancing “yield in the present with necessary investment in the future.” Genuine leaders don’t just milk the organization in the short term, but seek to deliver reasonable results immediately while investing for future performance. Lafley states “We deliver in the short term, we invest in and plan for the midterm, and we place experimental bets for the long term.”
  • ORGANIZATIONAL CULTURE: “Shaping values and standards.” Lafley argues that “the CEO is uniquely positioned to ensure that a company’s purpose, values, and standards are relevant for the present and the future.” Of course, the culture and values need to guide the organization towards what matters most to it, to meeting its purpose, and satisfying its stakeholders.

To me, the Drucker-Lafley view on the CEO as a bridge between boundaries inside and outside the organization, can be extended a step down in the organization to other “chief” roles. The CEO’s vision and strategy to deliver value to the stakeholder to the role is fulfilled in part by the chief information officer (CIO) and chief technology officer (CTO). Together, the CIO and CTO marry needs of the business with the technology to bring them to fruition. Within the organization, the CIO is “outward” facing toward the needs of the business and the CTO is “inward” facing to technology enablement. Together, like two sides of the same coin, they execute from the IT perspective for the CEO.

Similarly, the chief enterprise architect (CEA), at the next rung—supporting the CIO/CTO, is also working to span boundaries—in this case, it is to technically interoperate the organization internally and with external partners The chief enterprise architect works to realize the vision of the CEO and the execution strategy of the CIO/CTO.

The bridge the CEO builds links the internal and external boundaries of the organization by defining stakeholders, scope, business strategy, and organizational culture. The CIO/CTO build on this and create the strategy to align business and technology The CEA takes that decomposes it into business, information, and technological components, defining and linking business functions, information flows, and system enablers to architect technology to the business imperative.

Three levels of executives—CIO, CIO/CTO, and CEA, three bridges—inside/outside the organization, business/technology sides of the organization, and business process/information flows/technologies within. Three delivery mechanisms to stakeholders—one vision and organizational strategy, one technical strategy and execution, one architecture plan to deliver through technology.


Share/Save/Bookmark

November 11, 2008

Improving Project Management and The Total CIO

IT projects are notorious for coming in late, over cost, and not meeting the customer’s needs.

CIO.com has an excellent article on ways to improve project management in an article entitled, “When Failure is Not an Option,” by Meredith Levinson (3 July 2008).

For organizations, good project management is a critical success factor!

“Project management is the number-one success factor for getting anything done in the organization. A firm’s ability to execute its strategy lies with its ability to manage projects,” according to Sam Lawler, the director of GlassHouse Technologies’ project management practice.

Yet, for years, organizations have faulted CIOs and IT departments with failed IT projects. As recently as 2004, a study by The Standish Group found that only 29% of IT projects “were completed on time, on budget, and with all features and functions originally specified.”

Project management methodologies work when business and IT work together as a team.

There are various methodologies being employed to try to improve project’s success, such as PMBOK and ITIL. However, IT projects’ success depends on IT and business people working together to achieve results; if this partnership and collaboration doesn’t happen, then no PM framework will bring us the project success we desire. Our organization’s business people are critical to ensuring project success—they develop the business case, identify requirements/functional specifications, realign and improve business processes, and test technical solutions to ensure they meet mission and business needs.

No longer is it about tossing the proverbial hot potato to IT and then pointing fingers and assigning blame when something doesn’t work right. Instead, the business and IT people are on the same team, sharing accountability, and working toward the success of the project and the enterprise.

Performance measurement is a must:

Improved project management needs to be accompanied by measurement of project success and reporting on these to executive management. We can’t manage what we don’t measure. And we need transparency to senior management to ensure that everyone—business and IT—have “skin in the game.”

Further, there are trade-offs in project management between cost, schedule, and scope/performance. Changing one affects the others, so we need to manage projects harmoniously in this triad. If for example, a project is delayed or costs more, but delivers on added functionality requested by the business, then the project can still be a success. At the end of the project, success is defined by the business!
Share/Save/Bookmark

April 13, 2008

Strategy and Enterprise Architecture

Enterprise architecture develops the organization’s IT strategic plan and influences its business strategic plan. In order to do this, EA itself must have a strategic roadmap.
Harvard Business Review, April 2008, states that “companies that don’t have a simple and clear statement of strategy are likely to fall into the sorry category of those that have failed to execute their strategy or, worse, those that never had one. In an astonishing number of organizations, executives, frontline employees, and all those in between are frustrated because no clear strategy exists for the company or its lines of business.”
Elements of a strategic plan
What are the elements of a strategic plan?
  1. Mission— “why we exist;” this is the purpose of the organization
  2. Values—“what we believe in and how we will behave”
  3. Vision—“what we want to be
  4. Strategy—“What pour competitive game plan will be; this includes the following: A) Objectives—what we want to achieve: goals and objectives B) Scope—“the domain of the business; the part of the landscape in which the firm will operate.” C) Advantage—the means or initiatives that define how you will achieve your objectives; “what your firm will do differently or better than others,” defines your competitive advantage.
  5. Balanced scorecard—“how we will monitor and implement that plan” A strategic plan for EA
    According to the American Management Association, the mission statement defines what the ultimate purpose of the organization is. It tells who you are, what you are, what you do, who do you serve, and why do you exist.
    The mission statement takes the form of: The [blank] is a [blank] that [produces blank] for [blank] to [help blank].
    For example, the mission statement for enterprise architecture:
    The [enterprise architecture program] is an [office of the CIO] that [develops information products and governance services] for [the employees of ABC organization] to [improve decision-making].
    The values of EA are: driving measurable results, aligning technology with the business, information-sharing and accessibility, service interoperability and component reuse, technology standardization and simplification, and information security.
    The vision of EA is to make information transparent to enable better decision-making.
    The strategy provides the conceptual way you will pursue your mission and vision.
    Defining the objective, scope, and advantage requires trade-offs, which Porter identified as fundamental to strategy.” For example, a growth or market size strategy may obviate profitability, or a lower price strategy may hinder fashion and fit. The point is that an organization cannot be everything to everybody! Something has got to give.
    So for example, in EA, we must trade off the desire to be and do all, with the reality that we must focus on entire enterprise. Therefore, we distinguish ourselves from segment architecture and solutions architecture. In EA, we focus on strategic outcomes and delegate line of business architectures and systems architectures to the lines of business and solution developers.
    Finally, EA implements a balanced scorecard by instituting mechanisms for monitoring and implementing its plans. These include performance metrics for both information products and governance services.
    In sum, to get a meaningful EA plan in place, we have to answer these fundamental elements of strategy for the EA program itself.

Share/Save/Bookmark