Podcast on IS Strategy, Planning, and Project Management

Kapitoly

Where Do Big Ideas Come From?

The Digital Suggestion Box

Building the Master Plan

The 10 Steps to Approval

The Life-Cycle Approach

Enter Agile Methodology

Agile vs. Life-Cycle

The Three Project Phases

Success Metrics and Project Actors

Choosing Your Partners Wisely

The All-Important Blueprint

Evaluating the Options

Making the Choice

Building and Testing

Going Live and Staying Alive

Final Thoughts and Farewell

Přepis

Chloe: Exactly! So it’s not just a brilliant idea popping into someone’s head. It’s about making sure that idea actually pushes the entire business forward.

Oliver: That makes so much sense. Okay, for everyone just joining us, you are listening to Studyfi Podcast, and we've dived straight into the deep end.

Chloe: We have! We're talking about where new IT and information system projects come from. And there are really two main sources.

Oliver: Let me guess. One is the big, grand vision from the top, right? The business strategy?

Chloe: You got it. That's called strategic alignment. It’s the fundamental idea that any investment in technology has to support the company’s main goals.

Oliver: So if a company’s goal is to have the best customer service, their IT projects should probably focus on that.

Chloe: Precisely. At a basic level, the business plan comes first, and the tech plan follows. But it can get even more advanced.

Oliver: How so?

Chloe: At an advanced level, technology isn't just a tool to support the business—it's part of the business strategy itself. Think about how companies use data and digital processes to create completely new ways of making money.

Oliver: Right, the tech itself creates new opportunities. That’s a huge shift in thinking.

Chloe: It is! But it’s not all top-down. The second major source for new projects comes from the ground up.

Oliver: You mean from the employees who are actually using the systems every day?

Chloe: Exactly. These are called development requests. An employee might notice a problem, a bottleneck, or just have a great idea for an improvement. A well-organized company needs channels for those ideas to be heard.

Oliver: It's like a suggestion box, but for tech. I like that. So who gets to put ideas in this box?

Chloe: All sorts of people! You have departmental users with ideas for their daily operations. You have managers who see the bigger picture across several departments. Even the IT managers or the Chief Information Officer, the CIO, can submit requests.

Oliver: What about ideas from outside the company?

Chloe: That’s the fourth group! The environment. A new law might force a change, or a major customer or supplier might have a new requirement. It can come from anywhere.

Oliver: So when someone submits a request, they can't just write 'The current system is bad, fix it' on a napkin, right?

Chloe: Hopefully not! A good request identifies the applicant, describes the problem in detail, explains why it's important, and even suggests solutions or the expected benefits.

Oliver: Okay, so you’ve got all these amazing ideas, from the CEO's grand vision to an employee’s smart fix. How do you decide what to actually do? You can’t do everything.

Chloe: You can't. And that is where the IS Plan comes in. Think of it as the master plan or the official rulebook for all digital projects for a set period of time.

Oliver: So this prevents the company from just chasing every shiny new piece of tech that comes along?

Chloe: Exactly. Without a plan, you get inconsistent investments that don't solve the most important problems. The IS Plan makes sure every dollar and every hour spent on tech is pushing the company toward its goals.

Oliver: But creating a plan like that sounds like a huge project in itself. What do you need to even start?

Chloe: It is! You need three key things first. First, an IS Committee.

Oliver: A committee? That sounds... very corporate.

Chloe: It's crucial! It’s a team with managers and IT experts who create, manage, and monitor the plan. They’re the guardians of the strategy. Second, they need to do some strategic thinking—look at the current situation, identify future tech, and align it all with the business vision.

Oliver: And the third thing is money, I assume?

Chloe: Of course. You need a budget and a clear approval process from top management. No plan moves forward without resources.

Oliver: Okay, so the committee is formed, they’ve got a budget… what’s next? How does an idea get into the final, approved plan?

Chloe: It's a pretty logical process, usually in about ten stages. First, they identify the big strategic challenges. Then, they gather all the project proposals and requests we talked about.

Oliver: And I bet they get way more proposals than they can handle.

Chloe: Always. So next, they discuss and understand each proposal, sometimes merging duplicates or clarifying the goals. Then comes a critical step: defining the evaluation criteria.

Oliver: Basically, deciding how they're going to score each project to see which ones are the most valuable.

Chloe: You’ve got it. They apply those criteria, rank the projects, and then review that ranking with the business managers to make sure it all makes sense.

Oliver: What if a project looks great on paper but just isn't... possible?

Chloe: That's the next step: a feasibility study. Is it operationally feasible—do people actually need it and will they use it? Is it technically feasible—do we have the tech and skills? And of course, is it economically feasible—do the benefits justify the cost?

Oliver: So after all that filtering, you have your final list of approved projects.

Chloe: Almost. The committee then details each approved project—deadlines, resources, everything—and prepares the final IS Plan. The last step is getting it approved by top management.

Oliver: And what about all the people whose projects *didn't* make the cut?

Chloe: This is so important. The committee has to communicate not just the approved projects, but also why other projects weren't chosen. It keeps people motivated and encourages them to keep bringing great ideas forward.

Oliver: That's a great point. So, once that IS Plan is approved... I guess the real work begins. Now you actually have to build the thing. How does that happen?

Chloe: Ah, now that’s a whole other adventure. Once the plan is set, the company has to manage the development of each of those projects, and that brings us right into our next topic.

Oliver: So, once a company decides it needs a new system, is there just one way to build it? Or is it like a 'choose your own adventure' book?

Chloe: I love that analogy! It's definitely more 'choose your own adventure'. There are two major philosophies here: the life-cycle approach and the agile approach.

Oliver: Okay, life-cycle. That sounds very formal and... circular?

Chloe: It's more linear, actually. Think of it like building a house with a very, very detailed blueprint. The development is divided into formal stages: analysis, design, build, test, and maintain.

Oliver: And you have to finish one before you start the next?

Chloe: Exactly. Each phase has to be completed and formally approved before you can move on. It's very structured, which is great for medium or large projects because you get clear documentation and planning.

Oliver: I sense a 'but' coming. What are the downsides?

Chloe: The biggest one is rigidity. It can be slow and expensive. And if you need to make a change halfway through? It's a massive headache. The requirements have to be super stable from day one.

Oliver: So, no changing your mind about where the kitchen goes after the walls are up.

Chloe: Precisely! The most extreme version is called the Waterfall approach. It's also called the cascading life-cycle, where everything flows down in a strict sequence. No going back up the waterfall.

Oliver: That sounds... stressful. Is there a more flexible version?

Chloe: There is! The Spiral life-cycle is a bit more forgiving. It allows you to go back to previous phases to make modifications. It adds some flexibility back into that rigid structure.

Oliver: Okay, so if life-cycle is the strict blueprint, what's the alternative?

Chloe: That would be Agile. And it's a completely different mindset. Instead of defining everything at the start, the requirements and solutions evolve as you go.

Oliver: Evolve how? Like, you just start coding and see what happens?

Chloe: Not quite that chaotic! Development happens in small, incremental chunks. Think of it less like building a house and more like sculpting with clay. You start with a basic shape and refine it over time based on feedback.

Oliver: That sounds much more modern. Where did this idea come from?

Chloe: It really gained popularity after the Agile Manifesto was published in 2001. Now, it's super common, especially for web and app development where things change so fast.

Oliver: So how does it work in practice? Do you just work forever?

Chloe: Not at all. After a brief initial plan, the project is broken down into short cycles called 'Sprints'. A Sprint usually lasts two to four weeks.

Oliver: And at the end of each Sprint...?

Chloe: You have something real to show. A working piece of the software. Then you hold a demo, the client gives feedback, and that feedback directly influences the next Sprint. There’s constant contact with the client.

Oliver: So let's break down the main differences. Life-cycle is all about long-term planning, right?

Chloe: Yes, and Agile is about short-term planning. With the life-cycle approach, all your tools and resources are defined and allocated from the start. In Agile, they can evolve during the project.

Oliver: And the biggest difference seems to be flexibility.

Chloe: Absolutely. For Agile, change is fundamental. It's expected. Improvements are continuously incorporated. For the life-cycle approach, changes are difficult and usually cost extra time and money.

Oliver: So they're for different kinds of projects. When would you choose one over the other?

Chloe: Here's the key takeaway. You'd use a life-cycle approach for projects with low uncertainty. Maybe it's a type of system the company has built before. The goal is to maximize efficiency with time and cost.

Oliver: And Agile is for... the unknown?

Chloe: Exactly! It's perfect for projects with high uncertainty, where it's hard to plan everything in detail. The main goal isn't just efficiency; it's to maximize usefulness and customer satisfaction. It's about building the *right* thing, even if you don't know what that is at the start.

Oliver: Okay, so regardless of the methodology, are there common stages to any big system development project?

Chloe: Yes, from a management perspective, we can boil it down to three main phases. First is the Analysis or Pre-implementation Phase. Second is the Implementation Phase. And third is Use and Maintenance.

Oliver: Let's start with that first one. Analysis. I'm guessing that's pretty important.

Chloe: It's critical! So many projects fail because of a poor analysis phase. This is where you define the objectives and requirements for the new system. It's a chance to rethink how the organization works, not just copy what's already being done.

Oliver: Who's in charge of that? Who talks to everyone?

Chloe: You appoint a project coordinator. They diagnose the current situation, talk to management and key users, and figure out what the new system needs to do to add real value. The result is a big report of requirements and objectives.

Oliver: What’s in that report?

Chloe: It outlines the goals, the expected benefits, and also the risks. A new system can cause huge organizational changes, so you have to anticipate that impact.

Oliver: Once you're past the analysis, how do you know if the project is actually successful? Is it just...'does it turn on?'

Chloe: I hope it's a bit more than that! There are three basic indicators. First, does it meet the objectives and requirements we defined? And these need to be measurable things, like system speed or improving customer satisfaction by a certain percentage.

Oliver: Makes sense. What are the other two?

Chloe: Budget and deadlines. Simple as that. Did you stay within the budget for expenses and staff hours? And did you meet the deadlines for each phase? If your deadlines keep getting extended, it's often a sign of inefficient project management.

Oliver: So, who are the people actually doing all this work? The 'actors' in this play?

Chloe: It's a mix of internal and external people. Internally, you need business profiles—the department leaders who will use the system—and technical personnel who know the company's existing infrastructure.

Oliver: And what about bringing in outside help?

Chloe: Very common. Companies often use external providers through subcontracting or outsourcing. Subcontracting is hiring a company for a specific project. Outsourcing is when you hand over your entire IT function to an external partner.

Oliver: So subcontracting is hiring a wedding planner, but outsourcing is getting married to the wedding planner's company.

Chloe: That's a surprisingly accurate way to put it! With outsourcing, they become a long-term technology partner.

Oliver: What are the benefits of bringing in these external experts?

Chloe: The biggest advantage is access to specialized expertise and previous experience. They've done this before with other companies. It also reduces the workload on your internal staff.

Oliver: But there must be risks. You're giving up some control.

Chloe: A huge amount of control. If the contract is weak, you can lose control over costs and deadlines. You can also become very dependent on that one supplier, and switching can be incredibly expensive and difficult.

Oliver: So choosing the right supplier is a massive decision. What should a company look for?

Chloe: A few key things. First, their proposal must directly respond to your company's specific requirements—no generic sales pitches. They should have experience in your industry. Think of it like hiring a surgeon; you want one who's done *your* specific operation before.

Oliver: Right. You don't want a heart surgeon operating on your knee.

Chloe: Exactly. You also look at their reputation, their financial stability, and the contract conditions. And crucially, what level of support and maintenance they offer after the project is 'done'. Because with software, it's never really done.

Oliver: That makes total sense. It’s a long-term relationship you’re building. So, we've talked about the 'how' and the 'who'. What about the tools they actually use to build these systems?

Oliver: Alright, so that brings us to our final, and maybe most practical, topic of the day. Procurement and maintenance!

Chloe: Yes! Getting the system and then keeping it alive and kicking. It's a huge part of the process.

Oliver: So where do we start? Do we just call up a tech company and say "build us something cool"?

Chloe: If only it were that easy! No, the very first step is creating a detailed requirements report. And here's the key part—it has to be created internally.

Oliver: Even if you plan to hire someone else to build it? Why is that?

Chloe: Exactly. You need to know *exactly* what you want before you even talk to suppliers. This document becomes your blueprint, and management has to sign off on it.

Oliver: That makes sense. It forces the company to get its own thoughts in order first.

Chloe: Precisely. This phase is critical. Everything that comes later depends on a clear, well-defined plan.

Oliver: Okay, so we have our blueprint. Now it's time to shop around?

Chloe: Yep! The company starts evaluating different alternatives. And there are a lot to consider.

Oliver: Like what? What are the big choices?

Chloe: Well, do you want a standard, off-the-shelf system or something custom-built? Do you build it in-house or outsource it? Open-source or proprietary software?

Oliver: And now there's the cloud versus having it on your own local servers. So many options.

Chloe: You got it. So, you send that requirements report to a few potential suppliers. They use it to prepare a detailed offer for the exact same request.

Oliver: So you can compare apples to apples. What should a good proposal include?

Chloe: It needs to cover how well their solution meets your objectives, their project methodology, timelines, and of course, the costs and what resources you'll need internally.

Oliver: How do you even begin to compare all that information? It sounds like a lot.

Chloe: You create a set of evaluation criteria. It's like a scorecard. You rank things like how well the system meets your technical needs, the supplier's reputation, and software details like update policies.

Oliver: And the cost, I assume? That has to be a big one.

Chloe: A huge one. But you have to consider *all* the costs—not just the price tag. Think about implementation hours, training for your team, new hardware... it all adds up.

Oliver: So it's not just a technical decision. It's also about organizational and economic viability.

Chloe: Exactly. Management looks at the total cost, the potential return on investment, and asks if the required changes fit the company culture.

Oliver: And if none of the options work out?

Chloe: They might decide none are acceptable. Then it's back to the drawing board to adjust the objectives or maybe even postpone the project.

Oliver: But if one is a winner, you sign a contract and it's official!

Chloe: That's the moment! It becomes a binding commitment.

Oliver: So once the contract is signed, the implementation phase begins. The real work starts!

Chloe: It does! First, you develop or acquire all the different components. This isn't just software. It's hardware like printers and servers, and even new business processes.

Oliver: What kind of processes?

Chloe: Things like defining security protocols, setting up rules for who can access what data, and how users will request reports. It’s the human side of the system.

Oliver: Right, you need to prepare the employees too.

Chloe: Absolutely. Communication is key. You run training programs, create manuals... you get everyone ready for the new way of working.

Oliver: Then comes the big test.

Chloe: Yep, system testing. Before it goes live, you have to make sure it works correctly under realistic conditions. End-users test if it meets their needs. Operators check if they can manage it.

Oliver: And you have to make sure all the old data was moved over correctly, right?

Chloe: Crucial point. You check that the migrated data is complete and accurate. If you find problems here, you have to make corrections, which might mean revisiting earlier stages.

Oliver: Okay, testing is done, everything looks good. Time to flip the switch!

Chloe: Almost! This is the start-up phase. There are two main ways to do it. The recommended way is a gradual start-up.

Oliver: What does that mean?

Chloe: It means the old and new systems run at the same time for a while. It's safer because you have a backup if something goes wrong.

Oliver: And the other way?

Chloe: That’s the abrupt start-up. You switch off the old system and switch on the new one all at once. It's riskier, so your testing phase has to be incredibly thorough.

Oliver: Like ripping off a band-aid.

Chloe: Exactly! Then, once the system is running, the work isn't over. Welcome to the maintenance phase.

Oliver: The never-ending story.

Chloe: It really is. Maintenance is a continuous process. You're constantly adapting the system to new user needs, fixing bugs, and responding to changes in the business.

Oliver: And it’s important to actually monitor if people are using it properly, right?

Chloe: Yes! You track how often it’s used and if it's still meeting business needs. So many powerful systems are underused because nobody checks if people are using them to their full potential.

Oliver: Wow, that's a comprehensive look at the entire lifecycle after the initial design. It's so much more than just writing code.

Chloe: It truly is. From that first internal report to the ongoing maintenance, every step is about connecting technology to the real-world needs of an organization.

Oliver: So to recap our entire discussion today... we started with understanding what an IS is, explored how we analyze and design them, and just now, we walked through the critical steps of procuring, implementing, and maintaining them.

Chloe: It's a journey from an idea to a living, breathing part of a company. It's complex, but when done right, it's incredibly powerful.

Oliver: Chloe, this has been fantastic. Thank you so much for breaking it all down for us.

Chloe: My pleasure, Oliver! It was great to be here.

Oliver: And a huge thank you to all of you for listening to the Studyfi Podcast. We hope you learned a lot. Until next time, keep learning, and stay curious. Goodbye everyone!