Skip to main content

A Note of Thanks

Written by Jonathan Malkin on . Posted in Articles.

I attended training with a new client last week.  The trainer and I work together to educate the client, begin gathering requirements and help relate the material more directly to the client’s business needs. 

As our session ended Friday the project sponsors pulled me aside to offer their thanks.  That got me to thinking, “I did my part and so did a lot of other people.” 

I’d like to offer my thanks to just some of the people who make my job possible at Plateau Systems:

  • Product Management and Product Engineering for making a great product.
  • Members of the Public Sector practice for coaching and guiding me.
  • My manager Scott Hardy for assigning me to challenging projects most suited to my skills.
  • Brett Lewis for developing the Solution Design Document I use to guide decisions in client meetings.
  • Andrea Malone in HR for handling benefits issues so I can focus on my job.
  • All the Business Analysts at Plateau ready to respond to email at a moment’s notice.   Sometimes I don’t know how I’d solve problems otherwise. 
  • All the trainers at Plateau who trained me and train my clients. 
  • The Plateau Technical Services Organization for creating the virtual environment running our enterprise application.  It allows me to run the Plateau application on my laptop where I test out scenarios for clients on the spot.

There are many others inside and outside Plateau Systems, including mentors, friends, and family that have helped my professional development. I could not possibly mention them all.

To all of you A BIG THANK YOU!!

Sincerely,

Jonathan Malkin

Jonathan Malkin is a Business Analyst at Plateau Systems.  Jonathan provides configuration, integration, documentation, and deployment support services for a leader in Talent Management Systems.  Jonathan’s areas of support include 21 CFR Part 11 Validation, SF-182’s, EHRI compliance and customizations to COTS software for which he has won multiple awards.  His experience includes work in the federal government, telecommunications, mortgage and banking, and custom software development industries.  Plateau Systems is a leading global provider of adaptable, unified web-based talent management software, content and services to onboard, develop, manage and reward talent.

Jonathan may be reached by email at [email protected] or by visiting his LinkedIn page at http://www.linkedin.com/in/jmalkin.

Seven Tips for Managing Your Online Reputation

Written by Cynthia Low on . Posted in Articles.

In a competitive job market, a polished professional reputation can make or break someone’s chances of landing a coveted position. And since the word google became a verb, that reputation includes information that can be found online. This is particularly true for IT professionals who are evaluated on their technical savvy.

As a growing number of employers search the Internet for information about job seekers, it’s become more important for applicants to actively monitor and maintain their professional reputations online. The current economic environment has made hiring managers increasingly cautious, and any information that raises a red flag can quickly take candidates out of consideration for a job.

Following are seven practical tips to help you manage your digital imprint

  1. Take stock. Discover what information about you — if any — already is online by performing a search using popular search engines. If you discover an item that you wouldn’t want hiring managers to see, ask the person who posted the information or website administrator to remove it. Similarly, untag any inappropriate photos of yourself.
  2. Activate privacy settings. If you belong to social networking sites or have a personal blog, adjust your privacy settings so you control who has access. 
  3. Exercise discretion. When interacting online, be selective about which venues you participate in and who you allow into your personal and professional networks. If you regularly contribute to blogs or forums, give thought as to how your statements may be interpreted by those outside your community. Consider using a pseudonym if you wouldn’t want a potential employer to see your posts. You can use BlogPulse or Technorati to track online conversations about you or your sites.
  4. Network wisely. When using professional networking sites such as LinkedIn to look for job opportunities, behave graciously with everyone you encounter and follow posted protocols. Thank anyone who assists you, and be sure to return the favor when possible.
  5. Stack the deck. Business information websites such as ZoomInfo allow users to post information about themselves, so consider including details about your professional involvement and qualifications on these types of forums.
  6. Share your insights. Posting useful advice and commentary on industry forums and authoring online articles in your area of expertise can add to your credibility.
  7. Monitor the conversation. Set alerts using Google or other tracking services under your name so you receive an e-mail notification every time something new is said about you online.

Professionals should always post prudently — not just when they’re looking for work. The business world is more transparent than ever, which means people need to be aware that what they say and do online can have both positive and negative consequences.

Dave Wilmer is Executive Director of Robert Half Technology, a leading provider of information technology professionals. Robert Half Technology offers online job search services at www.rht.com. For additional tips on conducting an online job search, download a free copy of Search Smarts: Best Practices for Conducting an Online Job Search at http://www.rhi.com/onlinejobsearch.

ITIL for BAs – Part VII; What Makes a Service Valuable?

Written by Terry Longo on . Posted in Articles. 1 Comment on ITIL for BAs – Part VII; What Makes a Service Valuable?

So much of a BA’s life revolves around functional requirements that the non-functional aka supplemental aka Quality of Service (QoS) requirements do not receive the necessary attention.

ITIL V3 defines the value of an IT Service as consisting of:

  1. Utility – the degree to which the service’s attributes have a positive effect on the execution of the customers’ tasks (e.g., steps in a business process), either by providing needed performance (functionality) or removing constraints; and
  2. Warranty – the robustness of the service with respect to availability, capacity, security, and continuity (that is, availability as a result of a catastrophic incident)

The diagram below depicts the relationships between warranty, utility, and their respective elements:

itilspart7_1.png

How useful is a service that is very fit for purpose but not fit for use?  The answer is that the service may have limited usefulness if its overall availability, security and responsiveness characteristics are either unpredictable or predictably very inconsistent.  What about a service that is highly available, secure and responsive, but does not offer the necessary functionality?  It is easier to see in this case the limited value, for the stakeholders’ primary interest is the solution’s functionality.

This model of a service’s value suggests:

  • Elicitation must address both sides of the “fit for use” questions – for example:
    • Not only “how available must the service be”, but also “what is the cost to the business when it is unavailable” and “what is the cost if we cannot recover the service quickly enough as the result of a catastrophic failure”
    • Not only how secure, but what are the costs and risks to the business without that level of security
    • Not only “what is the expected demand” but “what if the solution’s response time degrades with the specified demand parameters”
  • Full understanding of warranty requirements can only be gained relative to the stakeholders’ desired outcomes (this is in fact implied by the question “what are the costs/risks if the solution fails”).
  • Fit-for-use requirements are met through some combination of (a) the architecture that will accommodate the solution and (b) various design elements of the solution that are necessary to make up for deficiencies in the architecture relative to those fit-for-use requirements.
  • Early identification of fit-for-use requirements can help the solution team leverage as much as possible from the existing architecture and then include in the design only what is necessary to close any gap.

It is vitally important to capture the “costs and risks if it fails” for use by Service Owners and the IT support team once the solution is in operation, as that information is the basis for IT’s prioritization of pending Incidents.

As I noted in the previous post, the BABOK first takes on QoS requirements explicitly in the Requirements Analysis coverage (Chapter 6).  Hopefully you will interpret the above to mean that there is a lot of value in addressing those requirements (a) much earlier in the elicitation activities and (b) with the involvement of a core leadership team including the IT architect and lead software engineer (among others).

Here’s hoping that your 2009 is off to a great start!

Why Agile?

Written by Cynthia Low on . Posted in Articles.

What’s so Great about Agility?

The Agile approach to managing software projects has been getting a lot of play recently. Why are people talking about it so much? Is this just the latest “new thing”? Or is there some real value to it?

“Agile,” as a set of software development methods, was defined seven years ago, so the “flash in the pan” would have burned itself out long ago. The fact is that more and more organizations (from small shops to large corporations) are finding real value in Agility.

After defining what Agility is and is not, we will look at the value it can bring.

What is Agility?

The Agile approach has a number or key attributes that can be referred to as the “Essence of Agility.” They are:

  • Learning and adaptation – Traditional approaches expect that we can foresee how the project will unfold with reasonable precision. The Agile approach accepts that there are many things we cannot anticipate, so it is structured to allow us to first learn about those unknowns and then adapt to what we learn.
  • Collaboration – The Agile approach places high value on all stakeholders collaborating continuously, including the programmers and their customers.
  • Customer focus – The customer is the central focus of an Agile project and is actively involved throughout.
  • Small self-directed teams – Agility capitalizes on self-directed teams and recognizes that small teams can self-direct most effectively.
  • Lean principles – The principles that have been proven by Lean Manufacturing are embodied in Agility, especially concepts like “Just Enough” and “Just in Time.”
  • Progressive requirements elaboration – We expect to learn about the system requirements as the project progresses, so trying to nail them down in a full-blown specification at the beginning of the project doesn’t make sense. Agile projects establish a roadmap and elaborate the details as they are needed.
  • Incremental delivery – The best way to ensure we are building the right system is to regularly get feedback from our customer. Agility always includes incremental delivery of the product to the customer – at least for acceptance testing.
  • Iterative planning and adaptation – Agile projects place a high value on planning. They engage in planning at various levels of detail and engage in it regularly. Again, this is driven by the fact that we cannot foresee everything that is important, so we must adapt our plans as we learn.

What is Agility Not?

Many people have abused the term “Agility” by using it as an excuse for undisciplined practices. Some people wrongly believe that Agility means these things:

  • No documentation – The documentation that an Agile project produces is significantly different from what traditional projects produce, and an Agile team will always ask why various documents are needed. But they always document (in unique ways) their plans, requirements, designs, and whichever other artifacts provide value.
  • No planning – Agile projects actually engage in more planning than most traditional projects. They produce a high-level plan during project initiation, and they re-visit and adapt that high-level plan regularly throughout the project. They produce a plan of what they will do during each iteration of development, and they meet daily to check their progress and plan the day’s work.
  • No requirements – The Agile team’s Product Owner (customer) defines a Product Vision, and they work together to document the product’s high-level requirements (called the product backlog). Then, more detailed views of those requirements are elaborated upon and documented as they are needed throughout the project.
  • No schedule or budget control – Agile projects always operate within a “Time-Box.” That is, they have definitive start- and end-dates and are not expected to violate those dates. And because people’s time is the largest part of a software project’s budget, the time-box limits the project budget as well. The Agile mantra is, “We will deliver the greatest possible customer value within the project constraints!”
  • Programmers doing whatever they like – The Customer has primary control over an Agile project. The customer is involved in all aspects of planning, prioritization, and status keeping throughout an Agile project. If the project team is not producing what the customer finds to be valuable, it is up to that person to re-direct the work. The team’s only role is to estimate what can be done in limited timeframes. The team’s customer determines how that effort will be directed.

The Value of Agility

There are many reasons why companies find the Agile approach (when it is implemented as intended) to provide value. The value that is cited usually includes:

  • The right product – The customer is continuously involved in the project, ensuring that valuable software is being built and prioritizing the work. In addition, the customer accepts or provides critical feedback on each increment of the product that is produced. With this level of involvement by the customer, there is no way that the wrong product can be built.
  • Quality – Agility always includes a strong focus on the quality of what is built. This includes not only the customer’s acceptance testing, but also many technical quality practices. Properly functioning Agile teams produce high-quality software.
  • Schedule and budget – Time-boxing of an Agile project means that its schedule and budget are rarely “over-run” If things don’t work out as planned, the low-priority features can be skipped or cut short. If an Agile project does need to extend its time-box it would be with their customer’s and management’s full concurrence.
  • Early warning – Because an Agile project is essentially a series of short mini-projects, problems become apparent very early, when they can be corrected.
  • Adapting to change – Change is a fact of business. An Agile project can adapt to changes in the business environment, within the organization, or with the customer much more effectively than a traditional project.

Every business values agility (lower-case “a”). What many are finding is that Agility (upper-case “A”) provides what it promises.

Copyright ©2009 Global Knowledge Training LLC  All rights reserved.

Alan Koch, PMP, is president of Ask Process. Inc., (http://www.askprocess.com/) and an instructor with Global Knowledge Training LLC. A longtime member of the business analysis community, Mr. Koch has 28 years experience in software development. He can be reached at http://ca.mc883.mail.yahoo.com/mc/[email protected].  

More Business Analysis Trends to Look for in 2009

Written by Cynthia Low on . Posted in Articles.

The last Business Analyst Times of 2008, reviewed some of the important trends to look for in business analysis, or requirements management and development (RMD) in 2009. A global panel of experts from ESI International has its predictions about trends that will impact business analysis this year. These trends, listed below, acknowledge the growing importance of business analysis as a strategic, cross‑enterprise discipline, essential to the success of systems development, process improvement and change, especially in today’s volatile economic environment.

Better Sight for Strategic Enterprise Analysis

As businesses work to ensure short-term viability as well as long-term security, the critical thinking, elicitation and assessments skills of  BA professionals will play an increasingly important role in helping senior management see across the enterprise to deliver more accurate strategic analysis.

The Rise of the Center of Excellence

The need to demonstrate the value of business analysis while increasing efficiencies will result in more organizations establishing centers of excellence.  Centers will increasingly be valued for setting methodologies and standards that enable consistent sight across the full breadth of the enterprise.

Increasing Role in Successful Change Management

As businesses retrench and react to the unpredictable economic environment, well-executed change management will help ensure that decisions made are delivered as planned.  Essential to that success will be BA expertise in helping organizations thoroughly understand and document the change criteria and their cultural and economic impact.

Proving the Value of RMD

Smart businesses will be looking to contain costs across all areas in 2009.  It will be incumbent on BA professionals to effectively measure the value of business analysis and demonstrate its ROI to justify continued support.

The Role of the RMD will Elevate Above the Project

The combination of greater organizational reliance on RMD to ensure enterprise-level success and the increasing value of RMD experience and expertise will result in RMD stepping up to greater roles at the program and portfolio levels.

BA Experts will be Prized Members of Service-Oriented Architecture Project Teams

As enterprise-wide solutions become imperative for cost containment and other efficiencies, BA professionals will be prized on project teams for their ability to see across the enterprise as well as for their change management skills.

Strengthened Collaboration of Business Analysis and Project Management for Best Practices

Projects will continue to become more complex and more expensive.  Collaboration between business analysts and project managers will play an increasingly important role in ensuring that projects meet organizational needs and deliver promised ROI.

Growth of the Business Analyst Leadership Gap

As businesses increase their reliance on business analysis to drive change, help contain costs, ensure project success and gain accurate enterprise-wide insight, senior management will recognize the need to grow more BA leaders. Organizations will place greater emphasis on business analysis-specific career tracks, professional development and certification to close the gap.

Higher Value of High-Impact Communications

Driven by a need to make faster, more cost-effective business decisions, the often background skill of effectively facilitating diverse groups to achieve consensus through high-impact communications will be moved to the fore as a key business analysis role.

BA will Facilitate Greater Use of the Agile Software Development Methodology

As organizations look to continuously become more streamlined and cost-effective, Agile development will be increasingly viewed as a key solution. Business analysis will be valued for its ability to increase understanding of pre-planning activities and the ability to validate information early, supporting successful use of Agile for streamlining and cost-containment.

Glenn R. Brûlé, director of client solutions for ESI International, has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. http://www.esi-intl.com/.