Podcasts about Business requirements

When I started Podscan, I wanted to go full local AI. Self-hosted, self-managed, self-serving. But that tune has changed. Here's what to think about when contemplating a local AI strategy.The blog post: https://thebootstrappedfounder.com/when-to-choose-local-llms-vs-apis-a-founders-real-world-guide/ The podcast episode: https://tbf.fm/episodes/390-when-to-choose-local-llms-vs-apisCheck out Podscan, the Podcast database that transcribes every podcast episode out there minutes after it gets released: https://podscan.fmSend me a voicemail on Podline: https://podline.fm/arvidYou'll find my weekly article on my blog: https://thebootstrappedfounder.comPodcast: https://thebootstrappedfounder.com/podcastNewsletter: https://thebootstrappedfounder.com/newsletterMy book Zero to Sold: https://zerotosold.com/My book The Embedded Entrepreneur: https://embeddedentrepreneur.com/My course Find Your Following: https://findyourfollowing.comHere are a few tools I use. Using my affiliate links will support my work at no additional cost to you.- Notion (which I use to organize, write, coordinate, and archive my podcast + newsletter): https://affiliate.notion.so/465mv1536drx- Riverside.fm (that's what I recorded this episode with): https://riverside.fm/?via=arvid- TweetHunter (for speedy scheduling and writing Tweets): http://tweethunter.io/?via=arvid- HypeFury (for massive Twitter analytics and scheduling): https://hypefury.com/?via=arvid60- AudioPen (for taking voice notes and getting amazing summaries): https://audiopen.ai/?aff=PXErZ- Descript (for word-based video editing, subtitles, and clips): https://www.descript.com/?lmref=3cf39Q- ConvertKit (for email lists, newsletters, even finding sponsors): https://convertkit.com?lmref=bN9CZw

Introduction: Welcome to another episode of "Art of Consulting" with Andy Fry and Cat Lam. Today, we're diving deep into the transformative magic of active exploration and the incredible ways it can spark creativity and open your mind.   The host, Cat Lam, kicked off another insightful episode in their ERP series. She welcomed Arlene Poon, a seasoned professional with over 15 years of experience in the ERP industry, particularly in large-scale implementations within the construction and utilities sectors. Exploring HCM: Arlene's expertise lies in human capital management (HCM), emphasizing its critical role within ERP systems. HCM encompasses both human resources management and talent management, serving as a foundational layer for various modules. HR's Human Touch: Arlene sheds light on the unique aspects of working as a business analyst in HCM, emphasizing HR's focus on employee well-being and celebrations. The human-centric approach of HR adds warmth and inclusivity to project environments, fostering a sense of community.   Understanding HCM Modules: Arlene delves into the core components of HCM, highlighting employee management as its cornerstone. Core HR information serves as a springboard for other modules such as benefits, performance management, compensation, and recruitment.   Building on Core HR: The conversation touches upon the iterative nature of ERP implementations, starting with core HR and expanding to encompass additional functionalities. Cat and Arlene discuss the foundational layer of HRMS (Human Resources Management System) within Oracle and its evolution over time.   HCM forms the bedrock of ERP systems, encompassing HR and talent management. HR's people-centric approach fosters a supportive and celebratory project environment. Core HR information serves as a basis for various HCM modules, facilitating streamlined operations and decision-making. ERP implementations typically begin with core HR before expanding to incorporate additional functionalities. Evolution of HR Systems: The conversation starts with an overview of the evolution of HR systems, from HRMS to HRIS to HCS, highlighting the integration of core HR and talent management modules. Integration and Third-Party Solutions The hosts discuss the integration of HR systems with third-party solutions like payroll and the considerations involved in choosing between a single system or best-of-breed solutions. Business Needs and Customization They explore how specific business needs, such as complex recruitment processes, may necessitate the adoption of standalone applications tailored to those needs. Position Management and Budgeting The conversation delves into the significance of position management in structuring organizations and aligning budgets with staffing requirements. Successful HR Implementations The hosts outline the key outcomes of successful HR system implementations, emphasizing improved reporting, analysis, and efficiency in managing HR processes. Preparation for Implementations They conclude by discussing the essential legwork organizations should undertake before engaging in an HR system implementation, focusing on documenting current processes and assessing data cleanliness. Data Cleanup: Arlene emphasizes the importance of starting with clean data to simplify conversion and migration processes. Tat agrees, highlighting how consistent data capture leads to smoother transitions. Engaging Business Analysts: They discuss the value of involving business analysts to ensure accurate understanding of business processes and requirements. Common Pitfalls:  Arlene and Tat share experiences of data conversion challenges and delayed implementations due to inadequate planning. They stress the need for a solid data conversion strategy and thorough understanding of business needs. Role of System Integrators:  Cat explains how system integrators, while proficient in technology, may lack deep knowledge of organizational data and processes. Arlene emphasizes the role of intermediaries like themselves in bridging the gap between HR expertise and technical implementation. Listening to Business Requirements:  They highlight the importance of prioritizing business requirements over technical capabilities and caution against overcommitting to system functionalities that may not align with immediate needs.   Patience in Implementation:  Arlene advises patience in HR system implementations, as organizations often phase implementations due to budget constraints. Building valuable data and functionalities takes time.   Conclusion: In this episode, Arlene and Tat delve into the complexities of HR system implementations, discussing both valuable insights and potential pitfalls. They explore the importance of data cleanliness, business process understanding, and effective collaboration between HR experts and system integrators. This episode provides valuable insights into the complexities of HR system implementations and offers practical advice for organizations navigating this critical aspect of HR technology. Arlene and Cat express gratitude for the insightful discussion and look forward to future episodes. They emphasize the importance of understanding business needs and maintaining realistic expectations during system implementations.  

Business Requirements are the foundation for any sort of digital transformation or ERP implementation, but what exactly are business requirements and how are they used throughout successful digital transformations? That's what I will be discussing today. #businessprocesses #erpimplementation #digitaltransformation ORDER MY NEW BOOK: The Final Countdown: https://thefinalcountdown.com/

Business requirements are the foundation for any Digital Transformation but what exactly are business requirements? That's what we discuss in this episode of the Digital Stratosphere Podcast. —————————————————————  DOWNLOAD MORE RESOURCES BELOW:  ——————————————————————  2024 DIGITAL TRANSFORMATION REPORT: https://resource.thirdstage-consulting.com/2024digitalentopreport   BUY MY NEW BOOK "THE FINAL COUNTDOWN": https://www.amazon.com/dp/B0CFQ44XRS?ref_=cm_sw_r_cp_ud_dp_08YCHTR0NRD4F42NDPG1   PHASE ZERO CHECKLIST: https://resource.thirdstage-consulting.com/phasezerochecklist   SOFTWARE BUYER'S GUIDE: https://resource.thirdstage-consulting.com/softwarebuyersguide   SUPPLY CHAIN MANAGEMENT PLAYBOOK: https://www.thirdstage-consulting.com/reports/mastering-the-chain-a-comprehensive-guide-to-supply-chain-management/   DIGITAL STRATEGY FRAMEWORK: https://resource.thirdstage-consulting.com/digitalstrategyframework   GUIDE TO ORGANIZATIONAL CHANGE MANAGEMENT: https://resource.thirdstage-consulting.com/the-definitive-guide-to-erp-hcm-organizational-change-management   20 LESSONS FROM 1,000 DIGITAL TRANSFORMATIONS: https://www.thirdstage-consulting.com/reports/ebook-20-lessons-from-1000-erp-implementations   ————————————————————  CONNECT WITH US:  ————————————————————     * YOUTUBE: https://www.youtube.com/@thirdstageconsultinggroup8228     * LINKEDIN: https://www.linkedin.com/company/third-stage-consulting-group     * INSTAGRAM: https://www.instagram.com/thirdstageconsultinggroup/     * TIKTOK: https://www.tiktok.com/@thirdstageconsulting     * TWITTER: https://twitter.com/ThirdStageERP CONTACT US TO BRAINSTORM IDEAS FOR YOUR DIGITAL TRANSFORMATION: info@thirdstage-consulting.com  

Joël has a fascinating discovery! He learned a new nuance around working with dependency graphs. Stephanie just finished playing a 100-hour video game on Nintendo Switch: a Japanese role-playing game called Octopath Traveler II. On the work front, she is struggling with a lot of churn in acceptance criteria and ideas about how features should work. How do these get documented? What happens when they change? What happens when people lose this context over time? Strangler Fig Pattern (https://shopify.engineering/refactoring-legacy-code-strangler-fig-pattern) Octopath Traveler 2 (https://octopathtraveler2.square-enix-games.com/en-us/) Empowering other departments (https://www.bikeshed.fm/388) Transcript: JOËL: You're the one who controls the pacing here. STEPHANIE: Oh, I am. Okay, great. Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: So long-time Bike Shed listeners will know that I'm a huge fan of dependency graphs for modeling all sorts of problems and particularly when trying to figure out how to work in an iterative fashion where you can do a bunch of small chunks of work that are independent, that can be shipped one at a time without having your software be in a breaking state in all of these intermediate steps. And I recently made a really exciting discovery, or I learned a new nuance around working with dependency graphs. So the idea is that if you have a series of entities that have dependencies on each other, so maybe you're trying to build, let's say, some kind of object model or maybe a series of database tables that will reference each other, that kind of thing, if you draw a dependency graph where each bubble on your graph points to other bubbles that it depends on, that means that it can't be created without those other things already existing. Then, in order to create all of those entities for the first time, let's say they're database tables, you need to work your way from kind of the outside in. You start with any bubbles on your graph that have no arrows going out from them. That means they have no dependencies. They can be safely built on their own, and then you kind of work your way backwards up the arrows. And that's how I've sort of thought about working with dependency graphs for a long time. Recently, I've been doing some work that involves deleting entities in such a graph. So, again, let's say we're talking about database tables. What I came to realize is that deleting works in the opposite order. So, if you have a table that have other tables that depend on it, but it doesn't depend on anything, that's the first one you want to create. But it's also the last one you want to delete. So, when you're deleting, you want to start with the table that maybe has dependencies on other tables, but no other tables depend on it. It is going to be kind of like the root node of your dependency graph. So I guess the short guideline here is when you're creating, work from the bottom up or work from the leaves inward, and when you're deleting, work from the top-down or work from the root outward or roots because a graph can have multiple roots; it's not a tree. STEPHANIE: That is interesting. I'm wondering, did you have a mental model for managing deleting of dependencies prior? JOËL: No. I've always worked with creating new things. And I went into this task thinking that deleting would be just like creating and then was like, wait a minute, that doesn't work. And then, you know, a few cycles later, realized, oh, wait, deleting is the opposite of creating when you're navigating the graph. And, all of a sudden, I feel like I've got a much clearer mental model or just another way of thinking about how to work with something like this. STEPHANIE: Cool. That actually got me thinking about a case where you might have a circular dependency. Is that something you've considered yet? JOËL: Yes. So, when you have a dependency graph, and you've got a circular dependency, that's a big problem because...so, in the creating model, there is no leaf node, if you will, because they both reference each other. So that means that each of these entities cannot be created on its own, the entire cycle. And maybe you've got only two, but maybe your cycle is, you know, ten entities big. The entire cycle is going to be shipped as one massive change. So something that I often try to do is if I draw a dependency graph out and notice, wait a minute, I do have cyclical dependencies, the question then becomes, can I break that cycle to allow myself to work iteratively? Because otherwise, I know that there's a big chunk that can't be done iteratively. It just has to be done all at once. STEPHANIE: Yeah, that's really interesting because I've certainly been in that situation where I don't realize until it's too late, where I've started going down the path thinking that, you know, I could just remove this one thing, or make this one change, and then find myself suddenly, you know, coming to the realization, oh, this other thing is now going to have to change. And then, at that point, there's almost kind of like the sunken cost fallacy [laughs] a little bit where you're like, well, I'm already in it. So, why don't I keep going? But your strategy of trying to find a way to break that cyclica...that is two words combined. [laughs] I meant to say circular dependency [laughs] is the right way to avoid just having to do it all in one go. Have you had to break up a cycle like that before? JOËL: Yes. I do it on a semi-frequent basis. The fancy term here for what I'm looking for when I'm building out a dependency graph is a directed acyclic graph. That's a graph theory or a computer science term that you'll hear thrown around a lot, DAG. I often like to...when building out a series of tasks that might also form a graph because you don't just model entities in your system; you might model a series of tasks as a graph. If there's a cycle in the graph, typically, I can break that using something like the strangler fig pattern, which is a way to kind of have some intermediate steps that are non-breaking that then lead you to the refactor that you want. And I've used the strangler fig pattern for a long time, never realizing until later that, oh, what I'm actually doing is breaking cycles in my task dependency graph. STEPHANIE: Hmm. I'm curious if you have noticed how these cycles come to be because I almost imagine that they get introduced over time, where you maybe did start with a parent and then you, you know, had dependencies. But then, over time, somehow, that circular dependency gets introduced. And I'm wondering if part of figuring out how to break that cycle is determining how things were introduced, like, over time. JOËL: In my experience, this happens in a lot of different ways because I'm using dependency graphs like this to give myself a mental model for a lot of different kinds of things. So maybe I'm thinking in terms of database tables. And so those might get a circular dependency that gets added over time as the system grows. But I'm also using it sometimes to model maybe a series of tasks. So I take a large task, and I break it down into subtasks that are all connected to each other. And that doesn't tend to sort of evolve over time in the same way that a series of database tables do. So I think it's very context-dependent. But there are definitely situations where it will be like you said, something that kind of evolves over time. STEPHANIE: That makes sense. Well, I'm excited for you to get to deleting some potential code or database tables that are no longer in use. That sounds like a developer's dream [laughs] to clean up all that stuff. JOËL: It's interesting because it's...a move operation is effectively what's happening. So I'm recreating tables in another system, pointing the ActiveRecord to this new system, and then deleting the existing ones in the local database. So, in a sense, I'm kind of traveling up this dependency graph from the leaf nodes into the root and then back down from the root to the leaves as I'm creating and then deleting everything or creating in one system, and then going back and deleting in the other system. STEPHANIE: Got it. Okay, so not necessarily a net negative but, like you said, a move or just having to gradually replace to use a new system. JOËL: That's right. And we're trying not to do this as, you know, okay, we're going to take the system down and move 50 tables from one system to another. But instead, saying, like, you know, one at a time, we're going to move these things over. And it's going to be small, incremental change over the course of a couple of weeks. And they're all pretty safe to deploy, and we feel good about them. STEPHANIE: That's good. I'm glad you feel good. [laughs] We should all be able to feel good when we make changes like that. JOËL: It's going to make my Fridays just so much more low-key just, like, yeah, hit that deploy button. It's okay. So, Stephanie, what is new in your world? STEPHANIE: So this is not work-related at all. But I just finished playing a 100-hour video game on my Nintendo Switch. [laughs] I finished a Japanese role-playing game called Octopath Traveler II. And I have never really played a game like this before. I've not, you know, put in many, many hours into something that then had an end, like, a completion. So, at the end of this very long game that had a very, you know, compelling and engaging story and I was invested in all of these characters, and by the time the credits were rolling, I felt a little sad to be leaving this world that I have been in many evenings over the last couple of months. Yeah, I don't know, I'm feeling both a little sad because, you know like I said, I got really invested in this game, but now I'm also kind of glad to have some free time back in [laughs] my life because that has definitely been the primary, like, evening activity that I've been doing to relax. JOËL: It sounds like this game had a very, like, a particularly immersive world that really pulled you in. STEPHANIE: It did. It did. It has these eight, like, different characters that you follow, like, different chapters and all of their stories, and then they all kind of come together as well. And the world was huge in this game. There were so many little towns to explore. And I didn't realize I was a completionist type. But I found myself running around opening every chest, talking to every NPC, and making sure that I, you know, collected all of my items [chuckles] before moving on. I also finished all of the side quests, which is, I think, you know, how I managed to put in over 100 hours into it. But yeah, it was very immersive, and I really enjoyed it. I don't know if this will become a norm for me. I know there are some people who are, you know, JRPG diehards and play a lot of these kinds of games, but they're a real, like, time investment for sure. JOËL: Are there achievements for completing everything? STEPHANIE: Not that I can tell on the Switch. I do know that, like, on other systems, you can see your progress on having done all of the things there are to do. But I think it's actually kind of better for me to just play [laughs] to just, like, think that I've done it all but not really, like, have something that tells me whether or not I've done it because then I would feel a lot more neurotic, I think, about being able to let it go where I am now. [laughs] JOËL: Right. If we've got, like, an explicit checklist of things or a progress bar, then it feels like you got to get to all the things. STEPHANIE: Yeah, exactly. I think there are still, you know, a couple more things that I wrote down on my little checklist of tasks that I would want to do once I feel like I want to come back to the game. But for now, like I said, I watched the credits roll. I teared up a little bit, you know, thinking about and reminiscing on my adventure with these characters, and I'm ready to put it down for a bit. JOËL: Did I hear correctly that you made a checklist for this game of things you wanted to do? STEPHANIE: Yes, [laughs] I did. JOËL: That's amazing. I love that. STEPHANIE: Yeah, you know, there are just so many things almost kind of like work where I had to, like, break down some of my goals. I wanted to, like, hit a certain level. I wanted to, you know, make sure I defeat these bosses that would help me get to those levels. And yeah, I got very into it. It was definitely a big part of my life for a couple of months. I got it originally because I needed a game to play on my flight to Asia back when I went to Japan. And I'm like, oh, like, this looks, you know, fun and engaging, and it will distract me for my, you know, over 10-hour flight. Turns out it distracted me for many, many more hours over several months [laughs] since then. But I had a great time. So yeah, that's what's new for me. Again, it's something I'd never really done before. I will say though I am very behind on my reading goal as a result. [chuckles] JOËL: I feel like this is a classic developer thing to do is, like, use the tools that we're used to in our job and then apply them to other parts of our life. And now it's just like, okay, well, I made a Kanban board to track my progress in this video game. You know, or, in my case, I'm definitely guilty of having drawn a dependency graph for the crafting tree for some video game. So I feel you really strongly there. STEPHANIE: Yes, I'm nodding heavily in agreement. I think it just scratches the same kind of itch of, you know, achieving, like, little things and then achieving one big thing. JOËL: So, speaking of places that are nice to have checklists and, like, well-defined requirements, you and I were talking earlier, and you have recently found some frustration around having user stories be defined well on your current project. STEPHANIE: Yes. So I've been reflecting a little bit about my current project and noticing what I think I might call product smells; I'm not quite sure, just some things I'm seeing in our day-to-day workflow that is getting me thinking. And I'm curious to hear if you've experienced something similar. But I find myself being tasked with a ticket that is quite vague. And maybe this was written by a product owner, or maybe it was written by another developer. And it is not quite actionable yet, so I have to go through the process of figuring out what I'm really needing to do here. I think another thing that has been quite frustrating is, you know, maybe we do find out what we want to do. And, like, I'll go back into the ticket, write down the requirements that I gathered, and do the ticket. I'll ship whatever change was required, and then I'll hear back from someone in a meeting or either as a one-off request in Slack. And it'll be like, "Hey, like, actually, you know, we want this to be different." And maybe you previously said that "Oh, the value for something would be 30. But now we found out more information; it should be 20. And so could you, like, make that change?" And then I'm not really sure what the best way to document a change like that is because it, you know, maybe existed in the previous ticket, but now it has changed. And do I create a new ticket for this, or do I just go ahead and make the code change? Like, who would know this information that we're now carrying about 20 being the value for, let's say, like, days or not meaning something in the code that we're writing? And I guess I've just been really curious about how to make sure that this doesn't become the norm where a lot of these conversations are just happening, and, you know, the people who happen to be in them know that this change happened. But then later on, someone is asking questions about, like, hey, like, when did this change? Or I expected this to be 30. But is this, you know, behaving as expected? So that was [laughs] a bit of a nebulous way of describing just, like, this churn that I feel with being the executor of work. But then, like, a lot of these things changing above me or separate from me and figuring out how to manage that. JOËL: When you were describing this scenario where you've done the work, and then someone's like, "Oh, could we change this value from, like, 30 to 20?" I'm thinking in my mind of the sort of beam that a lot of our designers face where it's like, you know, they have a design. They work on it; they do it. And then show it to a client, and the client is like, "I love this design. But could we just shift this box over, like, one pixel?" Like, they're, like, tiny, tiny, little changes that are kind of requested for change after you've done, like, this big thing. And, oftentimes, those pile-up. It's like, you shift it one pixel. It's like, oh, actually, you know what? Why don't we do it two pixels? And then it's like never-ending cycles, sometimes of, like, minute little changes. STEPHANIE: Yeah. But the minute changes really add up into, I think, really different behavior than what you maybe had decided as a team originally. And in the process of changing and evolving, I don't really know where documentation fits in. I've been working on this project that had a pretty comprehensive product design doc, where they had decided upfront on, you know, how the application is going to behave in many different scenarios. But again, like, that has changed over time. And when I recently had to onboard someone new to this project, you know, we sent over this document, and we're like, yeah, you can, you know, feel free to peruse it. But it's actually quite outdated. And then, similarly, right now, since the features that I'm working on are going through QA, there's been a lot of back and forth about, I'm seeing this, but the doc said that Y is supposed to happen, and I'm not sure if that's a bug or not. And I or someone else has to respond with that context that we were holding in our head about when that change happened. JOËL: That's really interesting. And I think it varies a lot based off the size of the organization. In a smaller organization, you're probably doing a lot of the requirements gathering yourself. You're talking to all the stakeholders. You're probably doing the QA yourself, or you're walking somebody else through QA. Versus a large organization, there might be an entirely separate product team, and a separate QA team, and a separate dev team. And a danger that I've often seen is where all of these teams are just kind of tossing work over the fence. And all you're given is a, you know, a ticket of, like, execute on this. Basically, turn these specs into code. And then you do that, and then you toss it over the fence to the QA team. And they check does the code do these things? And there's so much context that can easily get lost from one step to another. That being said, I think a lot of devs find it frustrating to do some of the requirements gathering work. How do you feel in general about scoping out a ticket or doing follow-up conversations with the product team about, like, "Hey, your idea for the ticket is this. How do you feel about doing these things? Or what if we cut these things?" Are those conversations that you enjoy having? Is that a fun part of the developer role for you? Or do you kind of wish that, like, somebody else did all of that so that you could, like, go heads down just writing code? STEPHANIE: I think it depends. That's a great question. Actually, I have so many thoughts in response. So let me try to figure out where I want to go from here. But I think I used to not like it. I used to be stressed out by it, and sometimes I still am. But when I thought my role was purely executing, to receive a ticket that is a bit vague, you know, I might have been left feeling, like, stuck, like, not knowing where to go from there. But now that has changed a bit because I received some really helpful feedback from an old manager of mine who was kind of invested in my growth. And she really suggested learning to become more comfortable with ambiguity because that just becomes more and more your job, I think, as you progress in your career. And so now I at least know what information I need to go get and have, you know, strategies for doing so. And also knowing that it's my job, like, knowing that no one else might be doing it, and it might just be me so that I can therefore get this ticket done. Because, like you said, that problem of throwing the work over the fence to someone else, at some point, that doesn't work because everyone has too much on their plates. And you have to just decide to be the one to seek the information that you need. JOËL: I think one way that, as developers, we bring a lot of value is that we help to cut through a lot of that ambiguity. I think if we see our role as merely translating a requirements document into code, that's a very simplistic point of view of what a talented developer does. So, like you said, as we grow in our careers, we start dealing with less and less defined things. We often have to start defining the problems that we're given. And we have to have these conversations with other teams to figure out what exactly we want to do. And maybe better understand why is it that we want to do this thing. What is the purpose of it? How are we going to get there? And my favorite: Do we have to do all of these things to hit the minimum value of this goal? Can I split this into multiple tickets? I love breaking down work. If I can make the ticket smaller, I'm all about that. STEPHANIE: Yes. I'm well aware. It's interesting about what you said, though, is that, like, yes, that becomes, in some ways, our superpower. But, for me, where the pain comes in is when that's not part of the expectations, where I am maybe tasked with something that is not clear enough, and yet, the time that I need to find that clarity is not given the respect that it, I think, deserves to build a good product because the expectation is that I should already be making progress on this ticket and that it will be delivered soon. You know, in that situation, I wish I had been in the room earlier. I wish I had been part of the process for developing the product strategy, or even just, like, have come in earlier to be able to ask, you know, why are we building this? And, like, what are some of the limitations on the technical side that we have? Because often, I find that it is a little too...not necessarily too late, but it is quite down the road that we then have to have these conversations, and it doesn't feel good. JOËL: I think that's one of the powerful things that came out of the agile movement was the idea that you have these cross-functional teams, that you don't have a separate product team, a separate dev team, a separate QA team, a separate design team that are all these isolated islands. But instead, you say, okay, we have a cross-functional team that is working on this aspect of the product. And it will be some product people, some dev people, some designers kind of all working together and communicating with each other. I know, shocking concept. And even depending on the context, a big idea is that the client or the customer is a part of that team. So, when we at thoughtbot work with a client, especially when they are maybe a smaller client like a startup founder, we make sure that they feel like they are a part of the team. They are involved in various meetings where we decide things. They have input. You know, they're part of that feedback cycle that we build. But that can also be the case for a larger company where your internal stakeholders are kind of built-in to be sort of part of your team. STEPHANIE: I've seen so many different flavors of trying to do Agile [laughs] that it has lost a little bit of meaning for me these days. And maybe we've incorporated some aspects of it. But then that idea of the tight feedback loops and then a cross-functional team where everyone is communicating that part has gotten a little bit lost, at least on my project. And I imagine that this is common, and our listeners might be finding themselves in a similar situation where things are starting to feel a little more like handing off and a little more like waterfall. [laughs] I'm curious, though, if you found yourself being requested to make a change from what the original decision was, how would you go about documenting that or not documenting it? Where do you think the best place for that information about how this feature now is supposed to work where should that live? JOËL: Are you talking about where do we document that a decision was made to change the original requirements of a task? STEPHANIE: Yes. JOËL: In general, I think that should live on the ticket just because as long as the ticket is live, I think it's good to have all the context on that ticket for whoever's working on it to have access at a glance. Sometimes it's worth it to say, you know what? We don't want to just keep this ticket live for weeks or maybe months on end. Let's ship this ticket, and create a follow-up to make a change later, especially if it's a change that's less important where it's like, you know what? It would be nice to have if...but, again, like, scope creep is a real danger. And so, again, me with the aggressive breaking up of tickets, I love to say, "That's a great idea. It would make a great change, not part of this ticket." So oftentimes, those changes I will push them into another ticket. STEPHANIE: That's interesting. What about documentation beyond the current work? So I'm thinking about once, you know, a feature is delivered, how do people in the organization then know how this feature is supposed to work? Like moving forward as something that is customer-facing. JOËL: That can vary a lot by organization, I think because there's a couple of different aspects to this. You have maybe some internal-facing documentation; maybe some customer support people need to know about the way the interface has changed. And then you also have customer-facing documentation where maybe you want some sort of, you know, you want a blog post talking about the new feature or some kind of release notes or something like that to be shared with your customers. And compiling that might look very different than what you do for your internal service reps. STEPHANIE: Yeah, I like that. It's true that the customer documentation is really helpful. At least for, the product that I'm working on, it has very comprehensive documentation about how to use that for its customers. And that has been really helpful because, hopefully, that should be the truest [laughs] information out there. But sometimes, you know, I find myself in meetings where none of us really know what happens. For example, a question that was asked recently is our product has a free trial capability. But it was unclear what happens to all of the data that the customer is getting access to as a feature. Like, what happens to that data after the free trial ends? Like, if they then have purchased a license, do they still have access to their free trial data? If, you know, there's a lapse between then, does it just get deleted, or will it show up again? And no one really knew the answer to that. And I think that was another area that got my spidey senses tingling a little bit; I think because it reminded me of...there was a definition I read somewhere of legacy code that is basically when the person who has the most context about how a piece of code works and then they leave the company and that institutional knowledge no longer exists, like, that is legacy code. And I almost think that that also applies to product a little bit where a legacy product is something where no one quite knows what is supposed to happen, but it's still being used by users. JOËL: That's a really fun definition there. I think there's sort of two related questions that are slightly different here, which is, one, how does the code behave? So, what happens when someone's trial period expires? And it's quite possible that no one on the team knows what actually happens when that time expires. And then the second question is, what should happen when a trial expires? And it's possible, again, that the product team didn't think through any of the edge cases. They only went for the happy path. And so it's possible if that is also fully undefined and no one knows. STEPHANIE: Yeah, I like that distinction you made a lot because they definitely go hand in hand, where someone realizes that some weird edge case happened, and then suddenly, they're asking those questions. And, you know, we realized, like, oh, like, that just didn't have enough, like, intention or thought behind how it was coded. So, like, it really is; who knows, right? Just whatever seems to happen. And I think that this actually kind of reminds me of a previous episode we did about empowering other departments in the company because, ultimately, a lot of those questions about, like, how does this work? What happens? Ends up going to a developer who has to go and read the code and report back. And while, you know, we do have that power, it can also be a bit of a curse, I think. [laughs] JOËL: I think this is an area where, as developers, we're maybe particularly skilled. Because of the work that we do, our brains are kind of wired to think about all of the edge cases, and sometimes they can be really annoying. But I think there's a lot of value sometimes when maybe the product team comes to us with a maybe somewhat nebulously scoped ticket or a series of tickets for, let's say, a free trial period feature that only goes through the happy path. And then sometimes it's up to us to push back or to follow up and say, "Okay, great. We've got a bunch of tickets for a free trial period. Have you thought about what happens after a trial expires but the person hasn't converted to a paying customer?" And then, oftentimes, the answer is like, "Oh, no, we didn't think about that." And I think oftentimes, as developers, our job is to kind of, like, seek out a lot of those edge cases. And we have a lot of techniques and methodologies that we use to try to find edge cases, things like test-driven development, various modeling tools that we'll try to use to make sure that we don't just crash or do something bad in our code. But what should the actual behavior be? That's a conversation that we need to have. And hopefully, that's one that maybe the product team has already had on their own. But oftentimes, the benefit of having that cross-functional team is the ability to kind of have that back and forth and say, "Hey, what about this edge case? Have we thought about that? How do we want that to behave?" STEPHANIE: Yeah, that actually made me think about the idea of tech debt but almost at a product level, where, hey, it turns out that we have all of these things that we didn't quite think through, and it's now causing problems. But how much do we invest in revisiting it? Because, you know, maybe this feature is several years old, and it was working just okay enough for it to, you know, be valuable. But we're now discovering these things and, you know, like, do we invest in them? Or are we more focused on, you know, coming up with new things and new features for our customers? JOËL: That's a classic prioritization problem. It also kind of reminds me of the idea of an MVP. What are the actual, like, minimum set of features that you need in order to try out something or to ship something to customers? And, you know, maybe we don't need some special behavior if your trial account doesn't convert. Maybe we're okay [laughs] that you log in, and the app just crashes. Probably not, because we would probably want you to convert to a paying customer at some point. But maybe we're okay if you just get a screen that says, "You have no projects," when, in fact, you did have projects. It's just that you're no longer on the free trial. Again, for business reasons, probably we want a call to action there that says, "You have five projects. They are not available to you. Please pay to unlock your projects again." That probably converts better. But, again, now that is a business decision. And that becomes a prioritization question that the team as a whole gets to address. Sometimes it can also be some really fun prioritization things where if you're on a really tight schedule, you might ship some features live knowing that you have a time limit, but you don't have to necessarily ship other things. So let's say you've got a 30-day trial, and maybe you ship that before you've even implemented what the dashboard will look like after your free trial has expired, and that's fine because no one's going to hit that condition for 30 days. So now you've got 30 days to go out and handle that condition. And maybe that's okay because it allowed you to get to market a little bit faster, allowed you to cut scope, break those tickets, yes, and just move that much faster. But it does require discipline because now you're on the clock. You've got 30 days to fix that edge case or potentially face some unhappy customers. STEPHANIE: Yeah, I think that's quite a funny way to handle it. It's really ruthless prioritization [laughs] there. But what you said was very interesting to me because I was thinking about how there is such a focus on new feature development and that being the thing that will attract customers or generate more money. But there is something to be said about investigating some of our old features of our existing system and finding opportunities there. And oftentimes, revisiting them will reduce the amount of pain [chuckles] that, you know, developers feel having to kind of keep track or have an eye on, like, where things are airing out, but then don't have the time to really invest in making it better or making that part of the product better. JOËL: I think that's a great opportunity then to have a conversation with other parts of the team. Typically, I think you have to convert some of those into more of a business case. So the business people in the company or the product people might not care about the sort of raw metrics that you see as a developer. Oh, we got an exception with a stack trace in this part of our app. What does that even mean? But if you say, hey, people who signed up for a free trial and then didn't immediately convert within 30 days who want to come back a month later and convert are unable to do so. And we've seen that that's about 10% of the people who signed up for a free trial. Well, now that's an interesting business question. Are we losing out on potentially 10% of customer acquisition? I'll bet the sales and marketing people care a lot about that. I'll bet the business people care a lot about that. The product people probably care a lot about that. And now we can have a conversation about should we prioritize this thing? Are these metrics that we should improve? Is this a part of our code that's worth investing in? STEPHANIE: Yeah, I like that because, in some ways, asking those questions about how does it work? Like, that is really an opportunity because then you can find out, and then you can make decisions about whether it's currently providing enough value as is or if there is something hiding under there to leverage. JOËL: And I think that's one of the other places where, as developers, we provide value to clients is that we can sort of talk both languages. We can talk product language. We can talk business language. But we can also talk code. And so when we see things like that in code, sort of translate that into, like, what are the business impacts of this code change? Which then allows everyone to make the best possible decisions for the mission of the organization that you're a part of. So we've talked about a variety of sort of patterns and anti-patterns that surround working through some of this churn on a product. I'm curious, Stephanie, for you, what's maybe one concrete thing that you've done recently that you've found has really helped you navigate this and maybe help reduce some of the stress that you feel as you navigate through this? STEPHANIE: Yeah, I think, for me, one of the worst things is when that discussion is had in a meeting or a [inaudible 35:45] and then is not put anywhere. And so, one thing I've been making sure to do is either asking the person who made the request to write it down, either on the ticket or in Slack. Or I will write it down, you know, I will document the outcomes of what we talked about and putting it in a public space so that people are aware. I think that small action has been helpful because we hold so much of this in our heads. And I've been finding that it ends up being hard for people to rotate onto different projects and, you know, get onboarded and up to speed effectively because there's so much knowledge and context transfer happening. But even just putting it in a place where maybe it's not relevant to everyone, but at least they see it. And then the next time that they're asked or maybe, like, do come around to working on this, they, like, have some fragment of a memory that they saw something about this. So that has been really helpful. It actually dovetails really nicely into what we were talking about with opportunities, too, because once it's out there, like, maybe someone else will see it and have an idea about how it could be better or that change not being what they expected, and they can weigh in a little more. So that's what I'm trying to do. And I think it's also nice to see how often that happens, right? If we're constantly seeing things changing because we have a written record of it, that could be helpful in bringing up and investigating further as to, like, why is this happening? Like, why do we experience this churn? And is that something we want to address? JOËL: Yeah, because an element that we haven't talked at all about is any sort of feedback cycle or retrospective, where we can talk about these things and having that written trail and saying, "Oh, we changed this decision five times in the past week, like, really churned there." Now maybe that prioritizes it to be an important thing to talk about and to improve for the next cycle. STEPHANIE: What I feel really strongly about is when, you know, each individual on a team is feeling this pain, but it not being known that it's actually a collective issue. Because maybe these things are happening in one-on-one conversations, and we don't realize that, like, oh, maybe there is something bigger here that we could improve on. And so the more eyes on it there are, the more visible it is, I think, that the easier it is to address. JOËL: I love that, the power of writing things down. On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeee!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

You were given some Business Requirements. You understood them, converted them to Technical Requirements, designed it nicely, implemented it beautifully and tested it phenomenally well. At this point, you think you are ready to deploy those changes to Production. Sure about that? #snowpal #projectmanagement Manage personal and professional projects on https://snowpal.com.

Defining a clear set of business requirements is one the most important activities in a digital transformation. But what exaclty are business requirements and how do we use them? That's what we discuss in this episode of the Digital Stratosphere Podcast.   Be sure to download the newly released 2023 Digital Transformation Report to garner additional industry insight and project best practices. https://www.thirdstage-consulting.com/reports/2023-digital-transformation-r

Join Guy Lewis and Health and Safety expert Anna Maxwell as they talk about first aid and fire training. Anna talks about how the guidance from HSE gives you a good base level of information on what you need to provide in terms of first aid facilities for your employees. Anna also explains the importance of fire safety risk assessments, what they are and how they should be completed and kept up to date.

נחשון פינקו מארח את יוסי מרמרלי מנהל גלובלי לאבטחת מידע עסקי בחברת אורביה (הבעלים של נטפים) בשיחה על האתגרים של סיסו בחברה גלובלית מול אתגרים עיסקים משתנים מה היא הגדרת התפקיד החדשה של ביסו ומה השוני מסיסו איך מתמודדים מול הנהלה בחברה בינלאומית עם הבדלי גישות, מנטליות וטכנולוגיות הדגשים בבניית מערך הגנת סייבר בכלל ולעולמות התפעולים בפרט איך בוחרים טכנולוגיות להגנת סייבר בעולם שמתחדש לעיתים תכופות תוכנית פעולה להגנת תעשייה 4.0 וכניסת הענן לסביבות התפעוליות ועוד Nachshon Pincu hosts Yossi Marmareli, global BISO (business information security officer), at Orbia (the owner of Netafim), in a conversation about the challenges of CISO in a worldwide company facing changing business challenges. What is the new job definition of Biso, and what is the difference from CISO? How do you deal with management in an international company with differences in attitudes, mentality, and technologies? Emphasis on building a cyber defense system in general and the worlds of operations in particular? How to choose technologies for cyber protection in a world that renews itself frequently? Action plan for the protection of Industry 4.0 and the introduction of the cloud into the operational environments? and more

New research from Digital Realty in partnership with Hewlett Packard Enterprise reveals that nearly half (45%) of Irish organisations plan to migrate to a hybrid IT environment to leverage both on-premises systems and off-premises cloud/hosted resources. Findings reveal, however, a significant variance between enterprises headquartered in Ireland versus those in other countries (36% v 67%), showing Irish enterprises have been slower to adopt hybrid IT versus their international peers. The survey of 150 senior IT and business decision-makers, commissioned by Amárach Research, explored the opportunities and challenges that are driving enterprises from a cross-section of industries when it comes to digital and IT transformation. When asked what the biggest challenges their organisation faces, data management emerged as the most prevalent, with the key issues being identified as: Data security: 64 per cent of organisations identified data security as the main issue they would like to be addressed. Making better use of data: When managing data, nearly one in three (28%) of respondents said they grapple with the management of the ever-growing amounts of data within their organisation and over a third (36%) of organisations reported they would like to understand how to make better use of their data. Data regulation: Just under a quarter of the Irish enterprises surveyed (20%) want to more effectively manage evolving and diverse data regulation. Workload placement: Unlike the global shift away from storing data in owner-operated server rooms, many Irish enterprises continue to own and operate server rooms. Research shows, however, a significant (63%) reduction in the reliance of on-premises facilities over the next two years. “Irish businesses have rarely faced a more prolific time of immense challenges and constant change. From remote working to ongoing security concerns, and from supply chain issues to a proliferation of data; one thing remains true – security, including backup and recovery, is top of mind for Ireland's leading enterprises, be that IT security, data security or physical security. Add one more major consideration to this list in the form of connectivity – the demands associated with always-on data and self-service – the challenge for Irish enterprises is to modernise their IT offering in order to deliver for their business and staff, as well as for customers and clients,” said Séamus Dunne, Managing Director Digital Realty Ireland. With more than a half of respondents (54%) forecasting the total number of IT and business applications deployed by their organisation to grow anywhere from 11% – 50% in the next 12 months, and almost 40 percent (39%) of respondents stating that optimising connectivity at branch locations or employees working from home was a key network consideration; there has never been a more important time for Irish businesses to have the right IT infrastructure and ecosystem in place to scale and meet the changing demands of the current business environment. Lack of Skills Emphasises Importance of the Partner Ecosystem Alarmingly, just as the demands on IT infrastructure increases, another major revelation from the report showed that few organisations surveyed have the necessary resources or skills to meet future IT demands including security expertise (53%), compliance and governance (38%), and application transformation and redevelopment skills to support cloud migrations (28%). It comes as no surprise then that the research also showed that a third (31%) of Irish enterprises currently use systems integrators or managed hosting providers to manage their infrastructure. The ecosystem doesn't end there, with almost all the companies surveyed saying they rely on multiple software and hardware vendors, consultants, and cloud services providers to navigate their IT transformation journeys, with a fifth (21%) of companies stating they plan to use a data centre or colocation provider to support the depl...

https://sfbatraining.com/ Have you ever been assigned to work on a new project that you didn't really know anything about? This happens to all Business Analysts throughout their careers and it can be a little overwhelming. Don't worry my friend you are not the only one anxious at the beginning of a project. It doesn't matter if you have years of experience or if you just a newbie. At the beginning of a project we are all anxious. 1. Come on time and be ready! The very first assignment should be done so well that it not only pleases your team leader but demonstrates to stakeholders that you possess the ability to clearly detail the business needs and value-added approaches to deriving a solution. When I changed my job of over 18 years to take up a job in an institution that I knew little about, one of my first assignments was to assist the insurance arm of the business in implementing an electronic document management system. I started by understanding the process from existing team members, then went on to observe the process to prepare a presentation with best practice information to show team members time and cost savings they would achieve by implementing such a system. I also provided high-level process flows and steps showing the integration of the document management system in the business's workflow. I will not tell you that it was smooth sailing, but the quality of my work was apparent, and the stakeholders were able to use the information to present their case to the Board of Directors, who approved of the electronic document management system. 2. Go above and beyond the call of duty. While completing the task of assisting with the online document management system, the business was thinking of having clients complete and submit a form online, which they would use to give the client an estimated insurance quote. So I took the opportunity and did the additional work to show the business how an online insurance quote system would provide clients with even greater value instantaneously while obtaining contact information that the business could use to follow up and sell their services. 3. Determine which project phase the project is currently in. Initiation Phase: If you are lucky, you will start right at the beginning of the project. This means very few people really know very much about the project and you are not the only one who doesn't know what is going on! It is also a great time to be assigned because you will understand ‘the whole story' of the project as it unfolds. Analysis Phase: Very often this is the phase that most business analysts join a project. The main reason is that this is the phase during which the Business Requirements are being gathered, analyzed and documented. It is also typically the Phase after formal approval for the project has been obtained. So your goal is to get familiar with the stage the project is at and the main deliverables that has been created.

In this episode, we're discussing the all new, effective immediate policy: the SBA deciding to suspend bona fide place of business requirements for 8(a) construction contracts. We have Meghan Leemon from PilieroMazza, a business law firm that serves a strategic partner to government contractors and commercial business from across the United States in numerous industries.  Meghan counsels on a broad range of government contracting matters. She advises companies on small business procurement matters, particularly on issues related to eligibility and participation in small business federal procurement programs, such as the Small Business Administration's Service-Disabled Veteran-Owned Small Business, Women-Owned Small Businesses (WOSBs), 8(a) Business Development, and HUBZone programs as well as the All Small Mentor Protégé Program and the VA's VetBiz VIP program. She also assists clients in maintaining compliance with the FAR and small business regulations. Meghan discussed what does this policy mean, how does it impact small businesses, what is a bonafide office in the first place, why was it created and we also got into the other rules and changes that have been implemented recently that may be affecting you and your small business. Stay tuned for this episode, as Meghan shared helpful insights that would help your business.

Joe Biden Threatens To Use New Business Requirements To Drain Cashflow Of Private Companies Who Don't Force Employees To Get The Vax : American News Updates References: - Biden Wants People To Lose Their Job If They Don't Submit To Mandatory Vaccination: https://www.youtube.com/watch?v=Lxul5Mjs7dk

Yes, this is the most boring title ever, but this podcast episode isn't! Follow Us Frank: Twitter, Blog, GitHub James: Twitter, Blog, GitHub Merge Conflict: Twitter, Facebook, Website, Chat on Discord Music : Amethyst Seer - Citrine by Adventureface ⭐⭐ Review Us (https://itunes.apple.com/us/podcast/merge-conflict/id1133064277?mt=2&ls=1) ⭐⭐ Machine transcription available on http://mergeconflict.fm

Yes, this is the most boring title ever, but this podcast episode isn't! Follow Us Frank: Twitter, Blog, GitHub James: Twitter, Blog, GitHub Merge Conflict: Twitter, Facebook, Website, Chat on Discord Music : Amethyst Seer - Citrine by Adventureface ⭐⭐ Review Us (https://itunes.apple.com/us/podcast/merge-conflict/id1133064277?mt=2&ls=1) ⭐⭐ Machine transcription available on http://mergeconflict.fm

Erica Minton, L&I Industrial Hygiene Consultant, joins the program to discuss some of the key takeaways that all Washington State businesses should know in relation to COVID-19 requirements. Discover resources to find out the most current information and updates on COVID-19 related requirements, and the biggest challenges that businesses are facing when it comes to COVID-19 compliance.  To learn more, visit the below links:  https://lni.wa.gov/agency/outreach/coronavirus-covid-19-worker-face-covering-and-mask-requirements-questions  https://lni.wa.gov/safety-health/preventing-injuries-illnesses/request-consultation/    http://wisha-training.lni.wa.gov/training/articulate/maskselection/story.html  https://www.governor.wa.gov/   www.findyourphasewa.org https://www.coronavirus.wa.gov/  

Dave takes the mic for a solo podcast on business requirements and their role in your technology-driven project. View Dave's Requirements Checklist.

As shelter-in-place orders are lifted, businesses will enter uncharted territory. COVID-19 will permanently alter supply chains, workforce planning, service models, and growth strategies. Phase 2 of the reopening will allow non-essential retailers to offer curbside pick-up services and dine-in restaurants will open with specific requirements. Labor lawyer Chantelle Egan, who practices in the San Francisco office of the Seyfarth law firm, came on the program to talk about return-to-work issues that businesses face as California reopens.

Too often I see vendors selling the business a solution to their problem before a Business Case or Business Requirements have been developed. This spells disaster. Take the time to develop both your business case AND business requirements without your vendor involved. Then gather information from the marketplace. Don't waste time and money on letting a vendor sell you a solution before you truly understand what the marketplace has to offer.

In Today's episode we are highlighting a process to determine Business Requirements, Business Priorities, Business Drivers, Business Outcomes, Business Capabilities, and Business Solutions. If you follow this process, at the end you will know how to create a Business Plan for your organizations and customers that they can leverage for the next 1, 3, 5, and 10 years! Lets get started my friends! The post ZNDP 050 – Business requirements appeared first on Zigbits - Where Zigabytes are faster than Gigabytes.

In this episode, I talk with Jon Macy, Director @ Cerner about: * How he balances single customer requirements and popular requests * How he engages with the business * The business-focused platform-as-a-service that he’s effectively built for the organization * What he thinks makes a valuable technology partnership
 Jon is focused on building enduring architectures and systems at Cerner, and it shows in the way he talks about his role and challenges. It’s both reassuring to listen to, and certainly helpful to others on a similar path. P.S. Know who I should speak to next? Drop me a line at andrew [at] networkdisrupted [dot] com. P.P.S. Short on time? I send episode summaries to my email subscribers. Add yourself to the list if you’d like.

Business has requirements. And these requirements also must be put into practice everyday - Ethics, listening, vision, financial responsibility, planning, follow through and the list goes on. We need to look at these every single day as we run and grow our businesses. If you have a question or comment, send a text to 818.252.5682. www.lodge-co.com

Business has requirements. And these requirements also must be put into practice everyday - Ethics, listening, vision, financial responsibility, planning, follow through and the list goes on. We need to look at these every single day as we run and grow our businesses. If you have a question or comment, send a text to 818.252.5682. www.lodge-co.com

Why Innovation Shouldn’t Start with Business Requirements

Ribose has achieved STAR Attestation, Certification and C-STAR along with being one of the first adopters of STAR Continuous. What was the main driver? What was the approach to implementation and how did they weave the STAR controls into their current management system to build one holistic integrated process?Listen as Ron Tse; Founder and CEO of Ribose as he addresses these questions along with discussing what challenges STAR addressed and predictions on what can be expected in the global compliance landscape.

Graduate schools across the country are pumping out new batches of "data scientists" every few months. However, these young recruits are being denied a very significant piece of education that will legitimately allow them to excel in their new roles in industries across the world.While they come out of these programs very well versed in various programming languages, visualization practices, or data engineering methodologies, they lack a holistic view of what it takes to deliver a data product from business question to final implemented data product.This episode begins the conversation on how to change this.Data Couture is running a Kickstarter Campaign!!!! To help support the show head over to datacouture.org/kickstarter today!To keep up with the podcast be sure to visit our website at datacouture.org, follow us on twitter @datacouturepod, and on instagram @datacouturepodcast. And, if you'd like to help support future episodes, then consider becoming a patron at patreon.com/datacouture!Music for the show: Foolish Game / God Don't Work On Commission by spinmeister (c) copyright 2014 Licensed under a Creative Commons Attribution (3.0) license. http://dig.ccmixter.org/files/spinmeister/46822 Ft: SnowflakeSupport the show (https://www.patreon.com/datacouture)

For the past 30 years, I’ve been fascinated by all the new ways to automate our lives.  And in the last 10 years, many of those new ways have become commonplace. Doorbell cameras, watches that send health data to our ..... The post Is Failing Fast a Sign? Automating the Build of Voice Applications. appeared first on Alexa Dev Group.

In my last post, we discussed best practices for creating a script for your Alexa Skill. If you’re wondering what the heck an Alexa Skill is, check out my Alexa Skill 101 post here. If you missed Best Practices for ..... The post How to Write Requirements for Alexa Development appeared first on Alexa Dev Group.

In my previous posts in this voice assistant series, I have focused on the technical aspects of how to get started creating Alexa Skills and Google Home Actions. (If you missed those posts, check out Alexa 101 and Google 101.) ..... The post Best Practices for Scripting Your Alexa Skill appeared first on Alexa Dev Group.

Alyce Reopelle challenges some of the practices and assumptions we make about requirements elicitation. The post MBA160: The Art of Better Business Requirements appeared first on Mastering Business Analysis.

The right Business Requirements create a stable foundation for your project along with the Business Case. What makes the 'right' requirements? Here are my ideas. #Project Management #Business #Business Case #Projects

Chappell and Robyn join us for a lively episode wherein we discuss the language we use to describe ourselves and our work. With her recent transition to the private sector, Chappell gives us her take on agency life and the vernacular associated with it. Find out why the words we use matter, even just internally. Links Sidecar Communication Studies Product Requirements Document (PRD) Huge Business Requirements Linguistic Relativity Telephone Line World of Warcraft Chicken or the Egg Dilemma Anthropology Industrial Revolution Basic Income Socialism Squarespace “Verbal Designer” Why Women Don’t Apply for Jobs Unless They’re 100% Qualified Minimum Viable Product Heuristic Subtweet Agile Software Development Metahaven Design Sprint Fonts vs. Typefaces

What do I mean by 'Project Foundations'? I'm talking about things such as a strong Business Case and Business Requirements. You wouldn't consider building a house without plans, would you? Then why start a project without a detailed business case and requirements? You are setting yourself up for failure.

This week on CIO Playbook with Jeffrey Hurley, I am continuing our discussion on project management tools and approaches with Part II of how to develop your business requirements. I mentioned in last episode that there are multiple layers to … Continue reading → The post #153: Part II Business Requirements appeared first on Jeffrey Hurley, Global CIO, CTO.

This week on CIO Playbook with Jeffrey Hurley, I am continuing our discussion on project management tools and approaches with Part I of how to develop your business requirements. I have found that a lot of project management teams or … Continue reading → The post #152: Part I Business Requirements appeared first on Jeffrey Hurley, Global CIO, CTO.

To Function or Non-to-Function? We all know the golden triangle of software requirements: Business Requirements -> Stakeholder Requirements -> Functional Requirements. Ensuring that the right business requirements are elicited and analyzed ensures that you are solving the right business need. Stakeholder requirements ensure that the... The post TBAC 042 | Author Cast : How to Succeed at Analyzing Non-Functional Requirements w/ Roxanne Miller appeared first on The BA Coach : Advancing Business Analysis & Agility.

Transcript -- What is Service Oriented Architecture? Developers of Tesco Direct at IVIS and an SOA evangelist at IBM explain SOA's & their implementation.

What is Service Oriented Architecture? Developers of Tesco Direct at IVIS and an SOA evangelist at IBM explain SOA's & their implementation.

Transcript -- What is Service Oriented Architecture? Developers of Tesco Direct at IVIS and an SOA evangelist at IBM explain SOA's & their implementation.

What is Service Oriented Architecture? Developers of Tesco Direct at IVIS and an SOA evangelist at IBM explain SOA's & their implementation.