Skip to main content

Tag: Methodologies

What’s Done Is Done – Sprints

Written by Daniel Gullo on . Posted in Articles. 7 Comments on What’s Done Is Done – Sprints

In the first installment of the ‘What’s Done Is Done‘ series, we talked about what “done” means in terms of User Stories for various stakeholders in an Agile project. There are two aspects of “done” that are of primary concern: Completion Criteria and Acceptance Criteria. For this article, we will explore what “done” means for iterations, commonly referred to as “sprints” in Scrum.

Sprint Planning takes the form of a meeting involving the Product Owner, Scrum Team and Scrum Master. The Product Owner discusses the current Product Backlog, with a focus on the top-priority User Stories. The conversation involves the Product Owner’s explanation of the Stories, including the Acceptance Criteria and the Scrum Team seeking clarification so that they may make informed choices with respect to estimating and what they will commit for the Sprint.
The Scrum Team then provides estimates for the Stories, often in terms of Story Points using Planning Poker, and will then commit to what they believe is within their capacity for the Sprint. The product of this meeting is a committed Sprint Backlog, which represents the User Stories that the Scrum Team will work on for the Sprint.

The Scrum Team also uses this opportunity to create Tasks for the User Stories. This activity takes place during the second half of the Sprint Planning meeting and may or may not involve the Product Owner. As the Sprint progresses and User Stories are completed, they will be demonstrated to the Product Owner who then confirms that each User Story is “done.”

It may seem superfluous to have a discussion about “done” when dealing with Sprints, which are defined as time-boxed iterations. One might ask, “Isn’t a Sprint ‘done’ when the two weeks (or whatever duration) are over?” The short answer is “Yes, a Sprint is ‘done’ when it has run its originally scheduled duration.”

The sticky part comes into play when the Sprint is over but there are User Stories that have not been completed. Does the Scrum Team get credit for partial Story Points completed? Do the full amount of points carry over with the User Story to the next Sprint (or whatever Sprint the User Story is moved to)? Can the Sprint be extended if the Scrum Team was “close”? Before we answer these questions, let’s look at the initial commitment by the team, since this will ultimately impact what is completed within the Sprint.

When a new Scrum Team is formed, there is no collective past history to draw upon that indicates how much this team typically accomplishes. As time goes on, this “Team Velocity” tends to emerge. Let’s say that we are looking at Team Sigma and their velocity after 15 Sprints is 17 Story Points (SP). Initially, in Sprint 1, Team Sigma didn’t know that its velocity is 17 SP. They had to make a best effort at what they thought they could accomplish. They may have selected 20 SP as a nice round number and target. When Sprint 1 ended, they weren’t able to accomplish all of the Stories. Let’s further assume that the story they were not able to complete was 5 SP and that roughly half the work was “done.” Should they have taken the credit for something that is 50 percent complete?

No, they should not claim 2.5 Story Points because the point of the Sprint is to deliver potentially shippable features. That story is only half “done.” While 2.5 Story Points of work might be potentially shippable, that’s not what they initially planned. It is important moving forward for the team to take note that they actually accomplished 17.5 SP for that Sprint — doing so will help them come up with a better estimate for the next Sprint.

Given that the incomplete story is 5 SP but is “half done”, it makes sense for the team to keep the 5 point estimate but factor-in that item as if it were 2.5 SP. That is, when they plan, they will still plan for 20 SP, but they know that really, the 5 SP story is only really 2.5 SP worth of work remaining. That way, they are more likely to accomplish everything planned for in this Sprint.

The continuity that we are striving for in taking this approach is the work itself, not the accounting process for documenting the work performed and work remaining. The story is kept as a single unit with all its original tasks so that nothing is lost. When we start to split stories, there is overhead in trying to figure out what was really done and what wasn’t. and there is significant risk that the second half of the story will be pushed out and never completed. Assuming the first half of the work is not truly shippable without the second half, we are left with waste in the form of useless code.

Another possible scenario might arise where the Product Owner asks the team for a demo of the story that is 50 percent complete and determines that it is “done” from their perspective. If there aren’t any significant technical activities remaining, which would accumulate in the form of technical debt, the team can close the story and zero-out the work remaining.

Ultimately, the Sprint is “complete” when the time-boxed duration is over. It is “done” or “accepted” when the Product Owner has accepted and signed-off on all the stories in the Sprint. This doesn’t mean that the Sprint should be extended or discounted if there are discrepancies from the Product Owner. It means that there may be stories which carry-over into future Sprints. The way to reduce this risk is to provide demos to the Product Owner early and often throughout the Sprint. Following this practice eliminates surprises at the end and allows the team to fix things that aren’t up to snuff before it’s too late.

It’s important when considering these factors that the project team does not lose sight of the overall product vision. Yes, it’s important to define what “done” means at various stages in the life cycle. However, these definitions should add value to the product and, in the end, the delight of the customer.

In the next installment of this series, we will discuss what “done” means at the Release level.

Don’t forget to leave your comments below.

Daniel James Gullo, PMP. CSP, CSM of Trinacria Consulting is a proven leader in the field of Information Technology and Information Systems who advocates and evangelizes best practices and quality for projects in all areas of business.  Specializes in delivering software development and testing projects which are on-time, under-budget, and high-value. A professional with demonstrated success in Agile and traditional project / program management, business analysis, quality assurance, and consulting services.  A highly praised and recommended consultant with an extensive history of satisfied customers and clients.  Fiscally minded with both local and global experience.  Open to travel both domestically and internationally.  Effectively manages teams and resources around the globe both on-site and remotely.

The Agile PM—What’s the Big Deal about Commitment?

Written by Robert Galen on . Posted in Articles. 7 Comments on The Agile PM—What’s the Big Deal about Commitment?

FEATURENov9thAs I discussed in my last post, I’m a bit of an “odd bird” when it comes to certain aspects of coaching agile teams. For example, I like the notion of calling sprints either a success or a failure based on how the team swarmed around and delivered on their Sprint Goal(s). Many agilist’s struggle with using the word failure to connote team performance and delivery—some prefer avoiding it entirely.

Another term that causes angst within agile circles is the word commitment. Again, I personally like the word commitment. After finishing sprint planning, I like to ask a team to “commit” to their sprint goal. I like the visualization of going “hands-in” as a team—in formalizing their commitment. Sometimes teams even physically do it, which always makes me smile. I see commitment as being a bond within the team to deliver on a realistic goal that they determine as part of sprint planning. It’s a bond extended to the business and generates meaning and focus for the team. But again, I may just be odd and miss the true nature of commitment.

So, what does it mean to be committed?

Let’s start with a definition of the term.  From wordreference.com I found the following definition:

  1. the state or quality of being committed to a cause, policy, or person.
  1.  a pledge or undertaking
  1. an engagement or obligation that restricts freedom of action.

Given that definition, project leadership is always looking for a team to commit to a project—to its target date/schedule, scope, and cost. They’re looking for guarantees from the team to meet the projects’ inception views towards completion targets.

On the surface that doesn’t sound bad—does it? Bringing it back to software development methods, there’s a perceived difference in how “committed” teams are in Waterfall variants vs. Agile variants (Scrum, Extreme Programming, Lean, Kanban, etc.).

Waterfall (is) Committed?

The thought goes that since teams plan their execution thoroughly in Waterfall, to a set of documented requirements, that when the project begins they’re in a clear position to fully commit to the project.

They’re committed to the date, to the scope, and to the costs they’ve estimated. And if there is any “negative discovery” along the way, the team will somehow figure out how to “suck it up”, working harder and longer to meet their “commitment”.  No matter what happens along the way!

You’ll often hear management driving this behavior—reminding the team of their commitment and to work smarter and not harder. There might even be veiled and not so veiled threats, as to what might happen if they fail to…meet their commitment.

Agile (is not) Committed?

Conversely there’s a feeling that agile teams lack commitment. You hear this coming from nearly every executive, technology leader, and project manager who are adopting agile and struggling with forecasting project outcomes.

This comes from the basic tenet that teams commit to projects incrementally—as they gain more understanding of the work by implementing it in small chunks. That teams narrow in on their delivery target as they gain more understanding and collaborate with their customer. That teams can commit when they’ve made some progress and understand their delivery velocity.

In lieu of simply committing without knowing, agile teams focus on incremental delivery and incremental commitment; needing some time to truly understand the project complexity and their own capacity. Many misconstrue this prudence and transparency for a lack of commitment. But there’s also a truth to agilist’s struggling with the term.

nov9bob2

A quick diversion to the Scrum Guide

Ken Schwaber and Scrum.org publish something called the Scrum Guide. They recently (2011) published an update to the Scrum Guide changing the language used to reflect the team posture at the conclusion of Sprint Planning. Previous language had used “commit”, as in the team would “commit” to the work they identified and planned as part of their sprint.

The updated language changed the word “commit” to the word “forecast”—here’s a copy of the language change that I copied from the FAQ on the Scrum.org site –

Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.

This was one of six changes or adjustments that were made within the guide. I bring it up because it amplifies a common reaction in the agile community to the word commitment. At my core, I don’t understand the issue. It’s just a word.

 nov9bob1

Back to Waterfall vs. Agile Commitment

So are Waterfall teams more committed than their Agile counterparts? In the use of language around project targets and scope, it certainly appears so. But let’s get real. Waterfall projects rarely meet their commitments. I rarely do this, but I’ll bring out some statistics to make the point…

According to the 2009 Chaos Report examining the success rate of IT projects found that – 32% of projects succeeded, 44% were challenged or failed to meet some project goals, and 24% failed completely.

The key point here is the assumption that these were committed teams, yet literally 2/3 of the projects failed in some capacity. So I contend that commitment is simply a word. Not let’s look at commitment from a different angle—probably the right angle.

The Real Nature of Commitment

I don’t think team commitment comes from a methodology or a planning process—particularly for highly complex, technology-driven projects, with tremendous up-side risk because your teams are creating novel solutions to your problems.

Commitment is created by many factors and I don’t pretend to be an expert on it. However, it seems to me that some of the following are crucial to support an environment of commitment—

  • Teams commit to work that they have planned and estimated themselves; factoring in their true capacity and not influenced by unrealistic or artificial targets from their managers or corporate leaders
  • Teams commit to a compelling leadership vision, which leads to understanding project goals, determines strategies, and ultimately measures success
  • Teams commit to each other; so fostering an environment of teamwork, mutual accountability, trust, and professionalism
  • Teams commit to exciting and meaningful work; so communicate the ‘why’ and ‘impact’ of their work to inspire them
  • Teams commit to solid leaders—leaders who trust them to do their jobs and who provide sufficient support for them to succeed
  • Teams commit to doing good work. Work that balances competitive delivery against solid designs, creativity, work-life balance, and high quality
  •  Teams commit to providing total honesty and real-time transparency so that their leaders can make congruent adjustments; to leaders that can “handle the truth”.

Wrapping Up

So I still like to instill in agile teams that Sprints can either “Pass or Fail” depending on their efforts and behaviors and results relative to their sprint goal. And yes, I do expect a team to “Commit To” their plan to meet a sprint goal that they’ve established with their Product Owner.

I feel it’s not the word that is the problem. Instead, the question is—does the environment support the team in the areas I mention above in meeting their commitments? Point being—I don’t see commitment as a team only condition. I think the organization needs to establish a culture and an environment where commitment is supported. Where discovery and adjustment is supported, where honesty and transparency is honored, and where failure is tolerated.

If you have an environment that isn’t supportive, then yes, I can see changing the term and not using it. In that environment, then “forecast” would be a better term…as would dysfunctional. But I’m tremendously disappointed in the organization that can’t make congruent commitments across their teams and then deliver on those commitments.

So call me committed to An Environment of Commitment…

Till next time,

Bob

Don’t forget to leave your comments below.

References

  1. Top 10 Agile Phobias – http://www.slideshare.net/visuri/agile-phobias
  2. Chaos Report reference – https://www.projecttimes.com/wp-content/uploads/attachments/chaos.pdf
  3. Scrum Guide reference – https://www.projecttimes.com/wp-content/uploads/attachments/Scrum%20Update%202011.pdf
  4. Wonderful article on Estimation, Prediction, and Commitment – http://tynerblain.com/blog/2011/08/09/agile-estimation/

Project Management Tips and Tools

Written by Amy Lamare on . Posted in Articles. 6 Comments on Project Management Tips and Tools

Successful project management abides by several principles. Essentially, every project needs three components to be successful: it must come in on time, within budget, and to the degree of quality that is expected. Sounds easy enough, but every experienced project manager knows that anyone who counts their proverbial chickens before they hatch will not complete the project on time, budget, or with quality.

Successful project management has tended to rely on time-tested and proven methods of planning, managing, and charting workflow throughout the project cycle. The old saying, “When it’s not broken, why fix it?” can certainly be applied here; however, what if a new way of managing the workflow in a project cycle was more efficient, more accessible and more transparent to all members of the team?

Consider the fact that one of the toughest things a project manager has to do is maintain the focus of his or her team. Often the team members are not committed to just one project. They have other projects. Increasingly, members of a team may be located in different locations. This makes the job of the project manager harder. How do you build in strong standards and practices when one team member is in California, another is in Colorado and a third in Connecticut? New web-based project management solutions offer an alternative to traditional workflow charts and software. With an interface that tracks all aspects of the project, everyone on the team can check the status and check for tasks assigned to them while the project manager has one easy place to go and oversee it all.

This solution minimizes rework and keeps projects on track so that they can be delivered on time and on budget. With email notifications, when the project manager changes something in the timeline, all members of the team are notified. Every good project manager knows that the first plan they lay out will not be the one they stick with. Project Management, by its very nature, is about planning then re-planning and then tearing the timeline apart and planning it again. As a project progresses, it takes on a life of its own and the collaboration between the team members will, in part, dictate the timeline. A good project manager knows how to manage and adapt to this changing aspect of the life cycle of the project.

An aspect of project management that holds true no matter what the nature of the project is that all deliverables and activities must be visualized and communicated in great detail. At the start of the project, the entire team must come to an agreement on what the finished project will look like. This enables the entire team to focus their efforts in the same direction. Web-based project management solutions ensure that all team members stay on the same page even as the life cycle of the project evolves.

The scope of work of any project evolves — it is the nature of project management. However, if all members of the team are not on the same page and focused on the same end goal, time and money can be lost when the project gets off track. Therefore, it is important for the project manager to build the deliverables — or the stages of the project — incrementally. Step A leads to step B and then to step C and eventually the team will get to Z. A project that is not focused on a step-by-step building toward the goals will inevitably fall off track and lose time. Build a little at a time, obtain incremental reviews and approvals, and maintain a controlled evolution.

Project Managers are the gatekeepers of a project and as such must be firm and in control at all times. Basically, the project manager must fight for the time to make sure things are done right. It isn’t enough to simply be accountable for the project’s outcome; a good project manager will ensure that they’ve obtained the time, authority and resources needed to deliver successfully at each stage of the project’s life cycle. The key to success in this arena of the project lies in documentation. The more thoroughly documented the needs of the project are, the more focused the efforts of the team will be with leads to the direct causation of successful completion of the project.

A key component of a good project manager lies in their ability to be a cheerleader and a salesman. Not only do they have to sell the customer or client on the project, but they must cheer their team along to keep them focused and on track. Web-based project management solutions can aid the project manager in this task as they provide an accessible place for everyone involved in the project — whether on the team completing it or the people receiving the deliverables — to check in and track the stages of the cycles and the evolution of the final product.

Needless to say, a project manager would be nowhere without the people that make up their team. Each member has a specific skill set that is integral to the success of the project. By bringing together the best people they can, a project manager can often compensate for having too little time or money to complete the project. Skilled team members can compensate for areas in which the project is lacking. It is the project manager’s job to protect their team from outside interruptions? By preserving their working conditions, the project manager is taking out insurance on the end result. Web-based project management solutions that allow team members to check in and brainstorm without wasting valuable time are the next wave in project efficiency.

Don’t forget to leave your comments below.

Amy Lamare is a staff writer for CollectiveSoft maker of TeamWork Live, a leading project management software based near San Francisco, CA. Amy specializes in creative and concept development for team collaboration, project deployment and user experience.


Challenges and Sustainability of the Program Management Office

Written by Ricki Henry on . Posted in Articles. 10 Comments on Challenges and Sustainability of the Program Management Office

What’s a Program Management Office (PMO)?  Good question and one that’s at the heart of why many seemingly successful PMOs fail to thrive.  That is, they haven’t clearly stated why they should exist and exactly what they are supposed to accomplish.

Having established a PMO in the IT department of a local government, been a member of a team that established the PMO in a travel department of a fortune 500 company, and established many of the processes in an IT PMO at a gaming company, it’s no surprise to me that so many PMOs are born then die within a relatively short time.

  • 2006 PMI survey: Only 17% of PMOs have been in existence for more than five years
  • PMI 2007 white paper analyzing the current state of play: Almost 50% of survey respondents indicated the existence of their PMO was being, or had recently been, seriously questioned.
  • PM Solutions 2010 survey shows 50% of PMOs closed over the prior four years.

When you hear about seemingly successful, yet ultimately failed PMOs, you’ll find these recurring themes:

  1. No clear mission
  2. Lack of the right sponsorship
  3. Lack of compliance to PMO processes
  4. Failure to integrate into the business
  5. Lack of mature project, program, and/or portfolio management
  6. Failure to establish metrics and success criteria

1. Off-Target – No Clear Mission

The PMO must have a charter with a clear mission and vision statement so there is no confusion as to its aims and value.  Each PMO is different so it’s essential to the success of the PMO to identify what it will do in your organization.  Which areas will the PMO govern?  What specific objectives do you want the PMO to achieve in each of those areas?

Your sponsor didn’t request a charter for your PMO? – do one anyway. 

The business’s identifies their strategy, that is what they want to accomplish, and their tactical action plans, aka projects, define how they will accomplish it.  It is imperative to see a major objective of the PMO as the business unit’s key partner in achieving their tactical action plans.  If you do projects as an order taker, ‘tell me what you want’, without understanding the business need, you leave yourself vulnerable to implementing solutions that fail to achieve the business need.  If at the fundamental level your PMO is all about processes and not about helping the business achieve their plans, you’re on a road to failure.  It’s not about templates or dashboards it’s about enabling the business to achieve their business strategy through projects. The PMO must be seen as the enabler of business change.

2. Who’s Driving the Bus – Lack of the right sponsorship

When the PMO is viewed as a process organization it is often placed under a lower level manager.  This is consistent with PMOs that lack a business aligned mission, fail to report metrics, and with the perception in the organization that the PMO is just project process cops.

It’s easy to see, then, why when budget cuts come around the PMO is high on the list for elimination.  With no high level sponsor to fight for the continued value of the PMO and lack of understanding how the PMO is essential to achieving business strategy, PMOs become dispensable.

Clearly it’s not just having a high level sponsor, but having one that believes and understands the PMO mission.  In fact, to be safe, assume they have no idea what project management is, let alone what program and portfolio management is, nor what a PMO can do.   Remember that most people are unaware that project management is an approach to doing projects that requires special training and experience.  Worse yet, they believe that they do know what project management is.  After all they know what a ‘project’ is and they know what ‘management’ is, therefore they believe they know what ‘project management’ is.  I call this “the Donald Trump version of project management” a la the way he assigns a project manager in his Celebrity Apprentice show.  You know the “Hey you.  You’ve done projects before and you’ve managed before, right?  You’re the project manager”.

3. If Momma aint’ happy – Lack of compliance with PMO Processes

You know the expression “If momma ain’t happy, ain’t nobody happy”?  Well the same is true for project managers.  If the project managers ain’t happy, ain’t nobody happy.  For the PMO to be successful projects need to be successful.  For projects to be successful, program, project and portfolio management needs to be successful.  For these to be successful, project managers need to be successful.

If the project managers perceive the PMO processes to be just over head with little value, then they’ll do everything they can to short cut those processes.  So be sure the processes work for them and they’re not working for the processes.

Adopting new processes is a cultural change and it’s important to address how you will effect that change in the PMO implementation and sustainability strategy.  How are changes introduced?  Did the PMs have any input?  How were the PMs trained?  What support do the PMs have now?    

When project managers short cut PMO processes, the whole house of cards falls.  To ensure PMO processes are being followed, mandatory Toll Gate Reviews can be very valuable.  

PMOs that are involved in project manager quality, not just processes, are more likely to succeed.  Involvement can mean hiring the project managers (regardless of who they report to), providing skill development, and providing coaching and mentoring. 

PMOs who believe they exist to maintain dashboards and reports for upper management don’t get it.  Your key to PMO sustainability is to ensure that project managers are successful.

4. Because I said so – Failing to integrate into the business

Project participation from the business unit is essential to the success of projects.  Stakeholder representation, subject matter expertise, project champions, deliverable reviewers and verifiers, are business roles.  If the PMO has developed its processes without considering the impact on each business unit, then cooperation and support from the business will be hard to come by. 

Like the PMs, if the PMO expects the business to adopt new processes then this is a cultural change and it’s important to address how you will effect that change in the PMO implementation and sustainability strategy.  How are changes introduced?  Did the business have any input?  How were business representatives trained?  What ongoing project support does the PMO provide?  How do the PMO processes fit with the way the business operates? 

An overly burdensome project request process can alienate the business.  PMOs that require very little information at request time will be more accepted by the business than those that expect the business to provide highly complex and detailed information at request time.  It’s more business friendly to meet with the requester after the request is received and assist them with whatever additional information you need.  Don’t make them provide volumes of information up front just to get a request submitted.  It’s essential that the PMO is perceived as a partner of the business, not an adversary.  Be what helps them get things done.  Don’t be the biggest road block they have to getting things done.

5.  You can’t build the building without a firm foundation – Lack of mature project, program, and/or portfolio management

Expecting to implement a mature PMO with a “big bang” approach is another set-up for failure.  Assess your company’s maturity in project, program and portfolio management.  Then if there are major gaps to where you should be, address those gaps first.  It’s not uncommon for a sustainable PMO to take several years to reach a high maturity level.  Just be sure to bring value at every step along the way by ensuring the organization’s pain points are alleviated early in the PMO’s life.

Become successful in project management before working on program management.  Be sure your project manager’s skills and capabilities are at a level for them to succeed.  When that foundation is strong, develop a mature portfolio management. 

Don’t forget Resource Management.  This can be a real deal breaker for many PMOs.  PMOs that fail to do good resource management will be perceived as being ineffective.   The challenge is that you cannot manage resources effectively without being able to accurately estimate project durations so that you know when resources will be available.  Understanding this means ‘estimation capabilities’ rise to the top of the PMO’s ‘to do’ list and are critical to Project, Program and Portfolio success and therefore to PMO success.

Assess whether the PMO is nothing more than a repository of tools and templates, or if it is an enabler of achieving business benefits.  When the business perceives the PMO as the essential organization that enables them to achieve project benefits, then you have arrived.  If you’re viewed as process cops, you’re doomed.

To avoid being perceived as no-added-value overhead, be sure to have the right balance of process and governance with flexibility.  Take “lean” to heart and get the paperwork down to the bare bones.  Become the ‘go to’ people when projects are stuck or in trouble and any time a project manager needs assistance.  Never ever let PMO compliance be the cause of project delays.  Create scalable processes that vary by project type and size. 

6. You can’t manage what you don’t measure – Failure to establish metrics and success criteria

No one asked you to establish metrics for your PMO? – do it anyway.  No one asked you to define the success criteria? – do it anyway.  The concept that you have to “sell” the value of a PMO comes up in many PMO articles.  But if you look at other business units in your company they don’t sell the value of their unit, do they?  What they do is show their value in reports and scorecards. 

To do that they need to have their target goals (criteria of success) and their metrics that shows where they are against those goals.  You’ll see the sales goals and their current sales.  You’ll see Human Resources reporting their personnel retention goals vs. the number retained. 

Then when the ‘what have you done for me lately’ question comes up in budget cutting discussions, units that have consistently shown their value are not hit as hard as those who have not demonstrated value.  It’s no wonder that PMOs who do not continually and consistently show their value to the company are often the first to go in hard economic times. 

According to Gartner, IS organizations that properly implement a PMO will experience half of the project cost and schedule overruns compared with those who do not.  Metrics can show the business value (e.g. 95% of project KPIs are achieved in 90% of projects), functional performance value (e.g. rework is reduced by 15%) and service level value (e.g. Customer satisfaction 90% satisfied or very satisfied) the PMO brings to the organization.  Metrics are essential for getting needed support.  They demonstrate progress, value, and productivity.

And don’t forget to celebrate.  Celebrate project successes, project manager successes and PMO successes.

It’s unbelievable the number of apparently successful PMOs that end up closing their doors after a few years.  There’s no need for yours to be one of them.  

Don’t forget to leave your comments below.

Ricki Henry,

  • 19+ years as a project manager
  • Established the PMO at Clark County NV, co-developed two other PMOs
  • PMP, Six Sigma Green Belt, Certified Scrum Master, MS Project Server Black Belt, PMP exam preparation Trainer
  • Speaker on BA and PM topics


IT Methodology – Offering Small and Mid-sized Businesses (SMB’s) Operational Performance and Impressive Bottom Line

Written by Cameron Watson on . Posted in Articles. 6 Comments on IT Methodology – Offering Small and Mid-sized Businesses (SMB’s) Operational Performance and Impressive Bottom Line

As world market conditions continue to evolve, so too have the pressures and expectations being placed on organizations. In many cases, the difference between red and black ink can often be attributed to the operational effectiveness derived from the “IT Efficiencies” of the organization.

Since information technology became a part of the business mainstream, business stakeholders, IT practitioners and academia have debated the various and most effective organizational “IT Efficiency” solutions. Though opinions have differed, most concur that an “IT Methodology” is one of cornerstones any organization can leverage to increase its operational performance and bottom line. Many agree that an organization that utilizes an “IT Methodology” has a competitive advantage in its ability to deliver and support its products, business applications and day to day operations.

For the sake of context, “IT Methodology” can mean different things to different organizations and audiences. As a noun, “IT Methodology” can be viewed as the roadmap project managers and business analysts rely on to consistently deliver products and applications on time and within budget – examples include IBM’s Rational Unified Process, PMI’s Project Management, QAIassist’s Integrated Methodology, Prince2. As a verb, “IT Methodology” can be viewed as the various modes of travel (practices and techniques) a project manager applies while using the roadmap to get to their destination (completed project) – examples include waterfall, agile, spiral, rapid application development RAD.

The benefits of an “IT Methodology” are:

Repeatable Organizational IT Process – An “IT Methodology” (noun) can be applied as an organizational process. As a process, organizations are able to define, utilize and repeat a common approach used to develop and support their products and business applications. By utilizing an “IT Methodology” as a process, organizations are able to introduce corporate quality assurance (quality products and applications are produced when the process is followed) and organizational improvement (analyzing the metrics and measurements of how the process is being used).

Consistently Deliver Applications on Time & Budget – In being repeatable, an “IT Methodology” (noun) affords organizations reliability in how products and business applications are developed and supported. Project team members (stakeholders, business users and IT) are able to understand their roles and responsibilities, project plans can be defined and approved, and the necessary deliverables and artifacts needed to complete the project can be identified. Applying an “IT Methodology” establishes a degree of structure that project teams leverage (and re-use) to deliver their projects on time and on budget – the more often it is used, the more proficient the project team becomes at applying it – the more proficient they become the greater the savings in time and budget.

Optimize Communications (Stakeholder, Business Users, IT Project Teams) – An “IT Methodology” (noun) acts as the glue that keeps a project team together and working from the same page. This includes project stakeholders, business users and IT project teams. Project Managers are able to dedicate project resources to specific responsibilities and the creation of specific deliverables and artifacts as part of the project plan. Project team members have a clear understanding of their roles and responsibilities and procedures used to administer the project. Project Stakeholders will have a mechanism to quantify the status of the project team with regard to progress, risks and issues.

Incorporate Organizational Governance – An “IT Methodology” (noun) provides senior management a tool that can provide predictability (schedule, costs, quality) on how the IT staff develop and maintain products and applications. This predictability affords senior management flexibility to budget and prioritize what applications are to be completed, when they can be completed and what resources will be available to deliver these products and applications. It also provides senior management an ability to re-adjust the priorities of the IT resources to reflect the business priorities.

Establish Resource Diversity – An “IT Methodology” (noun) provides organizations a basis for developing cross-functional expertise in both the business and the IT sides of the house. As a resource learns more on how an “IT Methodology” is applied they can leverage that expertise to become effective in other areas of the business (i.e. an apprentice carpenter that has learned to use a hammer to build a dog house can rely and re-use that same knowledge when building a deck or a house). This offers flexibility in how resources are to be applied and offers staff an avenue to gain additional expertise and knowledge in other areas of the business.

Though the concept of increasing operational performance and bottom line through an “IT Methodology” may be obvious, there remains a huge gap in how various organizations are able to implement these solutions. Large sized organizations have traditionally relied on large sized IT tool vendors and consultancies to acquire and implement complex and all-encompassing “IT Methodology” solutions – in the majority of cases they have created internal Project Management Offices (PMO’s) specifically dedicated to implementing and supporting these “IT Methodologies”. SMB’s have not always had the same financial flexibility nor the same need to acquire and implement these elaborate and all-encompassing “IT Methodology” solutions offered by the large sized IT tool vendors and consultants.

In today’s world, SMB’s are being squeezed from many directions and must rely on their ingenuity and nimbleness to navigate through these challenging realities. All too often the difference between an SMB keeping its doors open and making a profit is a direct result of its operational performance and “IT Efficiency” – on whether or not it utilizes an “IT Methodology”. Although benefits can be derived from an “IT Methodology”, SMB’s must assess the other side of the ledger in the Return on Investment (ROI) equation – implementation requires addition considerations. They include:

Access to “IT Methodology” (noun) – Traditionally SMB’s have had limited options in acquiring an “IT Methodology”. Their only alternatives were (a) acquiring the complex all encompassing solutions offered by the large tool vendors and consultancies or (b) not using any one at all because the costs of acquiring these all-encompassing products and services are often too great.

Acquiring an “IT Methodology” (noun) – As more and more SMB’s are recognizing the competitive advantages of implementing an “IT Methodology” several vendors and consultancies are now delivering scalable products and services that afford SMB’s the products and services they require to improve their operational performance and bottom line. Scalable “IT Methodologies” (i.e. project management, software development, software testing) can now be acquired at a minimal cost – a standard licensing fee is applied. Licensing fee applies to the initial acquisition and a minimal monthly support fee.

“IT Methodology” Implementation – Upon acquiring an “IT Methodology” SMB’s must go through the exercise of having it customized (scaled) to ensure it is optimized to contribute to both operational performance and the bottom line. Though implementing an “IT Methodology” is unique to every organization, most SMB’s will incur costs associated with customizing the “IT Methodology” to their specific circumstances, training the staff on the applying the “IT Methodology” and coaching the staff through several initial projects.

Ongoing “IT Methodology” Expertise – As an SMB becomes more proficient at applying their “IT Methodology” there may come instances and temporary circumstances where they will require additional “IT Methodology” expertise in delivering or supporting additional products and applications. In these cases it will be advantageous for them to acquire consulting resources familiar with the “IT Methodology” – these resources will be able to make an immediate contribution to the project team and an impact on the delivery of the product or application.

As global competition continues to drive business and technology, organizations armed with an “IT Methodology” increase their operational performance and their ability to consistently deliver higher quality products and services to their clients. The result – more satisfied clients and an increase in bottom line.

Don’t forget to leave your comments below.

Cameron Watson is the President of QAIassist. QAIassist helps small and mid-sized organizations (SMB’s) increase their operational performance and bottom line through IT efficiency. QAIassist’s Integrated Methodology incorporates the disciplines and deliverables SMB’s leverage to consistently deliver quality applications on time and within budget. Visit QAIassist’s website-www.qaiassist.com