CIOs are under constant pressure to deliver custom development projects to meet business goals. Project planning and requirements management are critical to an effective development process. In this podcast, our expert will offer advice to CIOs on how to use their resources to successfully work with the business to recommend, manage and deliver on application development projects.
SPEAKER: Morgan Chmara, Info-Tech Research Group Inc.
BIOGRAPHY: Chmara is a research analyst at Info-Tech, where she focuses on a range of topics including human resources, software development methodologies and the politics of IT.
Read the full transcript from this podcast below:
Karen Guglielmo: Hello. My name is Karen Guglielmo, the editor of SearchCIO.com, and I'd like to welcome you to today's expert podcast on five ways to streamline your application development process. I'm joined today by Morgan Chmara, a research analyst at the Info-Tech Research Group, where she focuses on application development. As one of the experts on the applications team, Morgan works to provide Info-Tech customers with practical tools and advice on subjects such as development methodologies, requirements management, project management, and software quality assurance. Welcome, Morgan.
Morgan Chmara: Thanks, Karen. It's a pleasure to be here.
Karen Guglielmo: Great. As I mentioned earlier, we're here today to talk about the application development process. Morgan will spend the next 10 to 15 minutes offering advice on how to use resources to successfully work with the business to recommend, manage, and deliver an application development project. Morgan?
Morgan Chmara:Thanks, Karen. Well, software development is really about the translation of a user need or a business goal into a software product. It has arguably become the key strategic component of IT today. The conception, development, and realization of a new application can create a powerful competitive edge for any competitive enterprise. It can create market leaders, drive enterprise growth, and expand the possibilities of both business and its customers.
For too many software projects, development efforts get abandoned, finished late, delivered over budget, or even fall short of business expectations. According to Standish Group, 18% of projects fail outright. And Karen, we're talking about they either get canceled, or finished but not used. And another 53% are challenged in some way.
You know, it's really no secret; software development has become increasingly complex, especially as the scope of business apps widens and enterprise environments grow to include a mix of software components and technologies. Factor in constantly changing business requirements, competing priorities, and limited communication with end users, and the challenge of developing software becomes increasingly more difficult.
Here at Info-Tech, and in our discussions with clients, we find there are really five practices that streamline the software development process, and really position projects for success. CIOs can learn how to control their software development projects and become better equipped to deliver innovative software that will keep the business competitive and growing.
So Karen, those five practices are, first, ensure the business supports process change. Secondly, have a plan. Strike a balance between major project drivers. Third, have the right amount of process. Fourth, assemble the right people for the development team. And lastly, use proper project techniques.
So, first one: ensure the business supports the process change. Seems obvious, right? Sadly, among all the things that CIOs can do to streamline their app development process, this one tends to be the most overlooked. The reality is, the business not only supplies the funds for the project. I mean, really, they are the ultimate judge of whether the project has succeeded or failed.
So you're probably wondering why this is important. Well, automating a business process, or part of it, for that matter, inevitably means change for those executing the process. This change is positive in that automation should not be paving the cow path, but instead, it's more about automating a more efficient and effective approach to work. But distributing changes to, say, unprepared business units, well, that's only going to create unfavorable results. Simply put, if the business isn't committed to the required change, then, I mean, it's going to be no surprise that users will resist just using the new process.
Software that's not used, or not used correctly, it just results in the business benefit just really not being achieved. If the right business partners are not involved in the design or designing any form of change, ultimately, this can result in rework later for the software.
So what can CIOs do to streamline their apps process? What can listeners take away from this? Well, first of all, make sure the project has an identified business sponsor who's willing to play an active role in decision-making, trade-off, and communication with those in the business that must use the software. So specifically, elicit their understanding of project and product success. Ask them to make decisions on key trade-offs, issues, changes that need to be made, that sort of thing.
Make sure the necessary subject matter experts are involved. Make sure they're part of the reviewing and revising the business process. Provide them with ongoing status information. This is key. Inform them about risks. When they're forewarned, they're forearmed. If the project involves business process change, identify the risks involved in not having this driven by and actively managed by the business. IT cannot manage or own business change, but they can certainly enable it. As far as risk management goes, it's not unusual for IT to recommend a mitigation strategy for any kind of identified risks.
Secondly, I'd like to talk about the importance of having a plan and striking a balance between major project drivers. Again, Karen, for many listeners, this may seem obvious, but there are key aspects to planning that can streamline the development process, or ultimately have the opposite negative effect.
A project plan outlines the project scope, the deliverables, budget, key milestones, timeline, and resources required. The whole purpose of having a plan is to identify the scope of the project, estimate the work involved, and create a realistic and achievable project schedule.
Project planning begins with sort of a high-level requirements or scope analysis, if you will, that defines the boundaries of the software to be developed.
So again, what does this mean to our listeners, and what does this mean for CIOs that are looking to streamline their development process? Well, IT project managers have three key areas to manage in software development projects: time, scope, and budget. This is not new to any of us. It's hammered into our heads.
However, CIOs need to ensure that project managed discipline includes work to prioritize and balance these three, but must not forget a key fourth dimension, and that is quality. In order to streamline the development process, a balance between project scope, budget, time frame, and quality needs to be determined at the project onset. Make this priority setting and balancing a definitive and visible step in the early planning process.
This is not a place for anyone to make assumptions about what is important, either. A close working relationship with the business will ensure these dimensions are established and clear prior to any sort of work on the project actually beginning.
For our clients here at Info-Tech, there's been no such thing as a truly unlimited project. Constraints are real, they're normal, and priorities must be met. That's the reality. What's important, though, is getting the time, cost, scope, and quality priorities identified as early as possible, and using these to determine the best approach to the project and to assess project change requests on an ongoing basis.
The third practice I highlighted was the importance of having the right amount of process. Now, a common question for a lot of Info-Tech clients is, all right, I know process is important, but just how much process? And just to clarify to some of our listeners, this is sometimes referred to as a formal methodology. And how much do I need, or which methodology do I go with? Well, the short answer is, of course, it does depend.
However, as a rule, the more complex the project, the more essential process becomes. I think that's an obvious one. But think of process as structure. Done right, it can provide an appropriate framework for the development team to consistently achieve success.
Implementing the right amount of process doesn't have to be a massive, one-
size-fits-all approach. Certainly not. There's definitely instances where we have smaller, less complex, and less mission-critical projects that just may not even warrant formal process discipline.
But what can CIOs do that want to streamline their process? Well, a growing body of software development organizations implement process methodologies that improve development productivity and quality. Some of the best known and oldest process is probably the waterfall, where the development team roughly follows the steps of stating the requirements, analyzing the requirements, designing a solution approach, architect the software framework for that solution, developing code. There's some testing. Eventually, the project is deployed, and then there's usually some sort of post-implementation wrap-up. After each step is finished, the process proceeds to the next step.
There's also iterative development. On the other hand, iterative development prescribes the construction of an initially small, but ever-larger, portion of software.
Now, IT should be responsible for recommending the right development method. When evaluating an approach to take, our listener should consider whether the project we're dealing with is familiar territory with a predictable path and perhaps a defined deliverable, as this might lead to being a better fit for the waterfall methodology. However, if we're dealing with a project that's part of a new frontier with many uncertain outcomes, it probably tends to lean more towards an agile development process.
So Karen, as I move on, we'll now talk about the fourth key practice:
Assembling the right people. While all the above practices can position the project and project approach for success, recruiting the appropriate individuals for the project team, it can ultimately make or break the project. Therefore, assembling a team with the right mix of hard and soft skills is critical to the app development process.
Now, you might wonder, well, why is this important. Other than the obvious reasons, assembling a team with substantial experience in, say, and a strong commitment to delivering high-quality software will take a great deal of pressure off the developer, making the entire development process both easier and more successful. Not doing so, for example, assembling a team without adequate experience, well, this can have a negative effect, and potentially jeopardize both the design and long-term viability of the project.
Internal business software development projects, by their very nature, they're designed to meet a strategic business goal, and therefore, they require much more involvement and input from the people on the business side of the organization.
So you must be thinking, "How do I find the right people for my app development team? Where do I start? What sort of things do I need to be looking for?" Well, a lot of factors go into a good project team. For example, does the team gel? Do members share a common work ethic and goal?
Are they able to perform the tasks at hand? These are the sorts of questions we ponder.
Assembling a development team isn't always easy. You should be open to finding the right people from within both the IT group and from the business side. And in some instances, if your budget allows, you may even look for resources outside the company.
Now, although technical skills are very much important to the development process, I can't stress this enough: if your team doesn't have the necessary soft skills, it's doomed to fail. In-depth technical interviews can determine if folks on your project team can actually build a specific application, but my God, with the greater challenge is really in identifying and nailing those software traits. They're just necessary for success.
Some examples of these soft skills might include the ability to stay focused, the ability to be flexible and pragmatic, good communication skills. Wow, they go a long way. Teamwork. That's key. And negotiation skills. Your team needs to be able to mentally adapt to changes and incorporate them, but at the same time keep the company and the project's long-term goal in mind.
So one last key practice here is... it's about using the proper project techniques. So, you know, Karen, we're now at the point where you set up the project for success, you have the right people in place, you've got the right people in the right roles. The final practice is really about employing two key techniques to project planning and requirements management that are going to enable a smooth execution of the project.
Project planning and requirements management are critical to an effective development process. Karen, did you know that up to 50% of project rework is attributed to problems with requirements? In fact, of IT projects that fail, a whopping 70% are due to poor requirements.
So what can our listeners do that want to streamline the development process? Well, the answer is, requirements work is not finished once requirements have been gathered. This is a very big misconception about the whole requirements process. They must be organized, documented, analyzed, communicated, and managed throughout the entire project life cycle. I can't stress that enough. This ongoing requirements work impacts every project, large or small.
On very small projects, these activities, however, may be less formal. But as the project grows in size or complexity, more requirements management is needed to ensure a common understanding.
An effective requirements management process includes a set of activities that ensure alignment between the business, the business's need, and the IT solution, which ultimately reduces the risk of rework or project failure down the line. One key requirements management activity is to prioritize requirements. The project needs to have agreed-to definitions of must-do requirements, should-do requirements, and could-do requirements. This focuses the team and the customer on making sure that the key must-do priorities are indeed completed in the project.
For example, must-do requirements might be something like for legislative compliance within the time frame of delivery. Rank order high cost savings. Some should-do requirements, they're not as important, but still important enough. They might include compliance items with maybe a longer time frame for delivery, so they're not mission-critical, or the cost savings of revenue generation things, they're not high enough to make the must-do list.
And then finally, we've got the could-do requirements. Well, they're practically everything else. They're your nice-to-have requirements and additional features, but they're not essential and not critical to the final product.
Managing requirements in this fashion ensures the work in progress at any time accurately reflects the customer's current project priorities.
So I've talked a little bit about requirements. I want to talk quickly about change management. Change management is critical to project management. And, I mean, business events, they happen, and they change the priorities of requirements. And they can do that all the way up to the focus of the project. The project discipline itself, it needs to be flexible enough to handle this.
So what can our listeners do that want to streamline their development process? Project change control, Karen, can happen on any size or any complexity of project. However, it's up to IT to define how formal the process should be.
Change management itself is the process of controlling changes to the project environment. The change management process tends to include things like logging changes. Now, this one's key, assessing the impact on time, scope, budget, and quality, providing some sort of approval and rejection, overseeing change implementation, monitoring and reporting the status of change, and then some sort of closing change request or post-implementation review.
So Karen, there you have it. For our listeners, by adhering to these five practices which we at Info-Tech have gathered through various customers or clients of ours, CIOs can streamline their app development process by first of all, ensuring the business supports the process change, having a plan, and striking a balance between major project drivers, having the right amount of process, and assembling the right people for the development team. And lastly, using proper development techniques, CIOs can streamline their app development process and use their resources to successfully work with the business to recommend, to manage, and to deliver on their app development projects.
Karen Guglielmo: Great. And on that note, that does conclude today's podcast. Thank you again to Morgan Chmara for speaking with us today, and thank you all for listening. Have a great day.