Agile Zone is brought to you in partnership with:

Specialization in: coaching, training, mentoring, organizational assessments for all aspects of software development, and consulting on strategies & implementations of process improvement engagements. Expertise in all leading methodologies such as IBM Rational Unified Process (RUP), OpenUP, EnterpriseUP, and Agile approaches such as XP, Scrum, and DSDM. Over 15 years of experience in guiding companies toward improving the implementation of new process solutions and technology, providing services as an agile coach, process mentor, and trainer. Organizational change management leader, working hand and hand with organizations in developing a strategy for implementing an improved process and the resulting organizational culture changes. Focus is the company’s Return on investment (ROI) and helps manage how much effective change a given organization can adopt at any given point. Coached, mentored, and trained thousands of practitioners on all aspects of software development, conducted dozens of Conference presentations, authored many publications, sat on advisory boards, and chaired User Groups. Author of “Implementing the IBM Rational Unified Process and Solutions – A Guide to Improving Your Software Development Capability and Maturity, IBM Press 2007”. This is the book on how to implement & adopt RUP and make it agile, that was written at the request of the IBM Rational brand, and is based on more than a decade of real life practical experiences implementing, mentoring, and coaching on software development process engagements. Invited by the IBM Rational brand in 2003 to become a member of the Methods Client Advisory Group (CAG), providing input and direction to the development of RUP and other IBM methods. The group consists of 20 selected individuals representing expertise from around the world. Program Director of the largest Rational User Group in the country, Co-Discussion Facilitator of the Rational RUP Discussion forum for IBM’s developerWorks, and a recurring member (1 of 4) of the Process and Portfolio Management Panel of Experts IBM Rational Software Development Conferences for consecutive years. Frequent speaker at industry conferences on topics related to software development best practices, effective coaching & mentoring, and organizational change management. Joshua has posted 7 posts at DZone. View Full User Profile

When is an assessment not an assessment?

01.18.2011
| 1046 views |
  • submit to reddit

Stemming from an internal audit finding, one of the clients I regularly work with engaged me to conduct a few project assessments.  The projects in scope would be the initial project in a series of projects (releases) each under a program.  The preliminary meeting with the executive management team yielded a requirement to not use the regular assessment framework we have as well as any standardized criteria to measure against.  I posed the question, if we are not going to use any sort of framework to assess the work of the projects against defined criteria, which would enable the assessments to have consistent metrics across all projects (in applicable aspects) then is what you want really an assessment?

After some deliberation, what developed was more of a “risk appraisal”.  I was skeptical about the value of doing what appeared to be just an adhoc review of project team documentation and informal interviews of key/lead project team representatives. 

The focus became identifying risks when project number one would be completed and project number 2 would begin.  Just a few examples of risks that we looked for:

  • Incurring technical debt, where activities would be put off to a future project and with the passage of time greater levels of effort would be required and more funding as opposed to just doing something in the present time
  • The project team completing activities that were valuable but did not produce any formal documentation and project number 2 (or any successor in the program) redoing the same work
  • The project team not completing activities that they should have, the next project having the expectation that something was done and not planning or budgeting to do that work


The “risk appraisals” were quite valuable, although not an assessment, they provided good visibility into risks that had a high probability of materializing and significant impact to the subsequent project.

Joshua Barnes

Co-Founder

References
Published at DZone with permission of its author, Joshua Barnes. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: