 | Level: Introductory Jim Connolly, Vice President of e-Business Solutions, Union Bank
15 Nov 2004 from The Rational Edge: Software Development Life Cycle (SDLC) methodologies are more effective when managers complement them with techniques borrowed from non-IT disciplines. This article suggests ways to use such techniques along with Rational Unified Process, or RUP.
This article is the first in a two-part series discussing how to supplement the Rational Unified Process,® or RUP,® with techniques borrowed from complementary disciplines, such as accounting, product management, marketing, project management, and organizational behavior. Part I provides an overview of key business management concepts with an eye toward enhancing communication across staff levels -- from hard core developers to CXOs -- and improving planning and execution for software projects. Part II will focus on a case study involving the specification and design of PlanStat,™ a retirement services Web portal developed for Union Bank. It will show how the approach outlined in Part I is superior to the typical "code and fix" approach to software development by ensuring that the end product will have long-term, sustainable value.
Strategic planning
At the beginning of every year, I write out the strategic and tactical plan for the eBusiness division and the product line we call "PlanStat," which serves over 380,000 TruSource division retirement planning clients.1 I use RUP for managing my team's software development activities, and conceptually, our strategic plan document maps most closely to the RUP Vision Document.2
I use the strategic and tactical plan both to define my resource and budget needs and as a general guide throughout the year. Most important, I share it with the other company managers to lay a foundation for strong inter-departmental communication among our IT division and others, such as the sales and customer relationship divisions. Sharing this strategic plan enables divisions to better align customer touch points and to manage expectations for both internal and external customers. Table 1 shows an excerpt from one section of our 2004 strategic plan.
Table 1: Excerpt from a strategic plan for Union Bank's eBusiness division
Another benefit of the strategic plan is that it forces my organization to approach IT infrastructure development proactively, a refreshing change from the reactive mode that many IT departments are stuck in. For example, to implement the initiative "E-Enable paper-based processes using digital and electronic signatures," we will have to evaluate enabling technologies, such as Public Key Infrastructure (PKI), for purchase.3
Viewing management activities through different lenses
Although creating a strategic plan is a great first step for anyone considering a deployment with RUP,4 managers can also incorporate complementary techniques from other disciplines -- such as accounting, product management, marketing, project management, economics, and organizational behavior -- to help manage the software development process. Below, I will discuss how I gain valuable perspectives on my organization's projects by viewing them through the different "lenses" of other disciplines.
The managerial accounting lens
I look at each project in my department through a managerial accountant's lens. As part of the strategic planning process, I use a Balanced Scorecard approach5 to measuring the eBusiness division's performance, considering not only financial measures, but also customer, business process, and learning measures. In completing the technology strategy plan, I make sure that my division's goals align with the organization's by defining activities that will have a positive impact on these non-financial measures.
For example, I recognized that we needed to provide learning and support as we transitioned from Active Pages 3.0 to the new MS.NET framework in order to leverage, among other things, the ease of creating Web services for our PlanStat data warehouse. I decided to sponsor a contest: I would pay for all books as well as the certification exam fees for anyone who would study and take the Microsoft Certified Application Developer (MCAD) for Microsoft .NET exam. The first developer to receive the credential would be the project lead for additional phases of PlanStat as it matured in its product lifecycle.
The product management lens
When I look through a product manager's lens, I check to see whether the baseline customer experience for a given application (i.e., how secure, reliable, fast, and easy-to-use is the application?) matches up with what customers want and need. I solicit and act upon feedback from both sales and customer relationship personnel, who have frequent contact with both prospective and existing customers. Then, it is my job to communicate the information I glean to the developers, in a directly actionable form. This is where RUP (or another SDLC process) comes into play.
For example, for smaller projects, I condense many of the RUP artifacts into one concise and easy-to-read document that is geared for everyone from CIOs to developers. I share project details with the developers (e.g. cost/benefit calculations) so that they can better understand the business and assume a greater sense of ownership, and as a way of mentoring them for future management responsibilities. To compile this document, I translate customer requirements from our sales and customer relationship staff -- often from a variety of unofficial channels such as e-mail, telephone, and other conversations), describing the purpose, scope, proposed phasing plan, benefits, costs, assumptions, risks, security requirements, and functional requirements. Figure 1 shows a use case diagram used to capture an application's functional requirements.
Figure 1: Use case diagram for an application
Click to enlarge
I do something else that is not strictly a product management activity but is worthy of discussion from an engineering point of view. I often work with the developers to write a technical architecture document before proceeding with a formal peer review. For example, for a complex project such as PlanStat, we created more of the artifacts that RUP specifies, including action sequence diagrams that document program flow and class interactions. Figure 2 shows an action sequence fragment for our Plan Data use case requirement.6 Other times, for less risky tasks or projects, I only ask the developers to discuss and/or whiteboard their approach and to supply only minimal documentation.
Figure 2: Action sequence diagram for an application
The marketing management lens
It is also important to look through a marketing manager's lens. Does the development organization know who the target users are and what their needs are? Is your product designed with those target users in mind? It is beyond the scope of this discussion to detail techniques for achieving this objective; customer segmentation, factor analysis, and conjoint analysis are useful ways to analyze a customer base. Many marketing research firms specialize in these techniques, and for very large, expensive projects, it may be worthwhile to engage one. However, for smaller projects, in lieu of hiring professionals, managers can study competitor's offerings and determine their strengths and deficiencies.
In addition, managers should acquire knowledge about the new application's business domain (in my job that includes retirement investment plans and rules for 401(k)s, 457s, 403(b)s, etc.). This will better equip the manager to identify opportunities to add value and plan for features that customers will really use. For example, Union Bank was among the first to market with the new Health Savings Accounts (HSAs), which clients can use to pay for their routine healthcare expenses. We recognize that e-enabling the entire HSA sign-up process will help us to maintain our competitive advantage, significantly lower our transaction costs, and provide expedited services for our clients.
The project management lens
Of course, the manager must always be looking through the project manager's lens. At the most basic level, we can think of a project as a collection of tasks that a person or firm desires to complete within a minimal amount of time or at minimal cost. The project plan should capture the activities necessary to execute against the defined product strategy. In my company, I define the product release schedules and feature sets, and I manage against the major milestones (defined through RUP) required to meet the project plan. Throughout the project, I proactively communicate about the project's status to our sales and customer relationship management personnel.
I plan our projects using an iterative approach, the cornerstone of RUP. At the beginning of every iteration for a new release of PlanStat, I provide relevant specification and requirements documentation to the development staff. Each release period also includes other, smaller iterations of development activity. Using an iterative approach prevents the proverbial eleventh hour surprise: You need not worry that system components won't integrate or perform to your specifications.
For example, we recently integrated a new Application Programming Interface (API) called OmniConnect into our OMNI recordkeeping system. Using RUP's risk-driven approach -- top risks drive early requirements, design, implementation, and testing -- we deployed one class only in our production environment early in the development process. We made it functionally transparent to end users in order to quantify its performance and reliability. We discovered not only several unforeseen nuances of the API installation procedure that were specific to our production servers, but also that we needed to change our implementation methodology to achieve satisfactory performance. Had we not learned these things at the outset, we would have wasted programming effort and most likely missed our target deployment date.
When looking through the project manager's lens, it is important to review the project plan regularly for conformance with the strategic plan. Among other techniques, for most projects I conduct a weekly inspection of delegated activities. In my experience, merely asking for project status does not result in accurate information, as my staff tends to be overly optimistic. It is the manager's responsibility to validate progress and provide fine tuning for the activities team members are doing to execute against the project plan.
Many metrics are available to quantify progress. In his Rational Edge article, "Navigating with project metrics: Are we there yet?" Gary Pollice discusses several useful metrics.7 I have found that reviewing the "completed" features within the context of all features in a planned release provides a good starting point, but it does not provide the in-progress detail I need to make decisions necessary to meet development schedules. For example, to make a decision about whether to add overtime, bring in additional resources, reduce the number of deliverables, or postpone a feature set to the next release, I need a more granular gauge of developers' productivity. In his article, "Cannot Measure Productivity,"8 Martin Fowler says that assessing software development productivity is difficult because it is difficult to measure output. I agree. Therefore, I like to see with my own eyes, through demonstration, the incremental progress of feature development prior to final QA and code check-in. This approach is subjective but very effective. I regularly leave my office to sit with the developers and ask them to demonstrate the features they are working on. I also ask questions such as, "Why did you choose to code it this way? Have you thought about using approach "x"? How do you think your code will scale or extend? Have you thought about leveraging code from project "x" or "y" The dialog stimulates a healthy exchange of ideas and has enabled me to make the right decisions about pulling or postponing features in order to meet deadlines.
In addition to helping me gauge project progress, this dialog between me and the developers benefits projects in other ways. First, I can detect when a developer is stuck on a particular problem (and perhaps spending an excessive amount of time on it); usually I can provide the resources or information they need to get unstuck. Second, gaining firsthand knowledge about details of programming activities (which I am less exposed to because I am usually performing management activities) helps me plan for subsequent iterations of the feature set's architecture. Third, with every "eureka" moment I share with a developer -- when our collaboration results in a breakthrough idea -- I build trust and earn respect from my staff. These are pre-requisites for effective leadership. Finally, we are in a very dynamic environment, and each developer is involved in operations and maintenance activities that can distract from project work. Therefore, this informal dialog gives me an opportunity to discuss, one-on-one, the particular project milestones pertinent to each developer.
I maintain a master version of a project and its tasks using Microsoft Project. I also maintain a milestone-only view, using the Visio 2003 Project Schedule timeline feature. I like the timeline graphical presentation because it allows you to view multiple project milestones against a common timeframe, as shown in Figure 3. However, there is no automated synchronization for the development environment documentation, and, as the Microsoft Visio timeline and Microsoft Project milestones do not synchronize with each other, I must maintain them independently. In the future, I may consider using the IBM Rational ProjectConsole® module, which integrates with the IBM Rational Suite® development environment, to produce project status tables and charts based on data maintained in the metrics warehouse.
Figure 3: Sample project timeline
The organizational behavior lens
Once your staff is clear on what you expect of them and when, you must motivate and inspire them. To do so, you can look through the organizational behavior lens. According to economic theory, there is always tension between principle and agency: Individuals (agents) who are supposed to represent a group and look after its interests should not use their authority or power to help themselves at the group's expense, although the temptations are many. This is a classical problem that all organizations face. Discussing various theories about how to mitigate it is beyond the scope of this article. However, we can discuss organizational behavior theories about how to ensure that company interests and project goals at the top of each staff member's list.
A research study at the University of Waterloo, Canada found that the manner in which supervisors ask employees to undertake tasks makes a critical difference in the employees' performance, commitment, and satisfaction. The study determined that directness on the manager's part correlated positively with an employee's emotional commitment to the organization. Also, a manager's likeability predicted job satisfaction, turnover intention, and emotional distress. The takeaway is that managers should ask team members to complete tasks in an unambiguous, straightforward manner. They should also make an effort to establish a friendly relationship with each employee.
I often preface my requests with "I understand how busy you are, but are you able to help me with something important?" I explain why the request is important and how I plan to use the results so that the developer can think through the details with a better understanding and arrive at a better solution. Most important, I make certain there is no ambiguity about the due date. "I need it by Wednesday at 5 pm." If the request is somewhat complex, I usually take the time to write it down for the developer. Or, if I am pressed for time, I ask the employee to write down what I asked of him or her and then recap it for me -- so that I know we have a mutual understanding.
I never bark out requests such as, "I need a report of Web site statistics, as soon as you are able." This would not take into account all the other priorities or ASAP requests the developer may have. Instead of building rapport, such a request would seem dictatorial, a management style that employees universally dislike.
In my years as a manager, I have found that following these communication guidelines helps to create loyalty and encourage employees to go the extra mile for you.
Conclusion
The techniques I have discussed in this article for managing software development projects, processes, and people are based on the real world experience that I gained from managing the development of several high-transaction-based Web portals. In addition to the management methods RUP provides for different aspects of the software development lifecycle, practical and theoretical techniques can be borrowed from accounting, product management, marketing, project management, and organizational behavior. This approach helps me manage the software development process effectively and contributes to the ongoing success of Union Bank's PlanStat product line.
Notes
1For more information on PlanStat, please see http://www.trusourcepartners.com/asp/services_planstat.asp
2See the whitepaper on the IBM Rational Unified Process at http://www-128.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
3Actually, the e-enabling initiative is a continuation of 2003 objectives; consequently, we have already put the PKI into place.
4In my experience, transitioning to RUP deployment methodologies is best accomplished one project at a time, prior to any top down, organization-wide edict. Start with shorter duration, less risky projects, and create simple requirement documentation, making liberal use of graphics in the form of use case diagrams. Adjust and refine the process based on the existing organizational culture and SDLC process awareness and maturity.
5For more information on the Balanced Scorecard approach to strategy, refer to http://www.bscol.com/
6UML Diagrams created by Jeff Weyer, a consultant who co-architected the PlanStat application with me.
7http://www-106.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/pollice/index.html
8http://www.martinfowler.com/bliki/CannotMeasureProductivity.html
About the author | 
| | Jim Connolly is the vice president of e-Business solutions with the retirement services division of Union Bank. He has fourteen years of experience in organizing and managing multi-functional teams and divisions through implementations of Software Development Lifecycle (SDLC) and project management methodologies. He holds a B.A. from the University of California, Los Angeles, and is nearing completion of his M.B.A. at the University of California, Irvine. |
Rate this page
| |
