I'll definitely say that this is primarily a conversation that is not only about PowerApps but also is about what I've learned in (checks calendar)...thi- (checks calendar again)...thirty years of technology work/consulting. The process of getting any organization to pick up a specific technology is almost always a slog. Add in that being successful in the "low-code" space means definitely abandoning some "best practices" from traditional coding that will make people's heads explode.
The key thing to realize is that every single organization prioritizes one thing: results. If you just abandon everything else and focus on this, you'll be successful. Now, how long you'll be successful...maybe don't abandon everything. See some ideas below.
However, before you go, I do feel a need to state the following simply as my own moral duty due to what I'll be sharing below. Consider this my own personal ethical EULA for you to agree to:
By clicking this link and reading the article attached, I agree to use what I learned here for the betterment of humanity, my employer, my family, and myself (in that order of priority).
Overview
I don't have any specific love for the Power Platform after spending over a decade of hating Microsoft. Hate that is only slightly more than Google, but far less than Oracle. It's a spectrum of tech companies who occasionally impress you only to pivot back to their old ways the moment their marketing department has convinced you that they've changed.
However, Microsoft has really done some incredible work here that simply must be acknowledged. If you're in technology and looking for the "next thing", then there is still room to jump into this tech stack and make a massive improvement within your own organization. It is highly unlikely that even if your org has adopted it, that they've accepted all of the changes to the underlying assumptions about development that this kind of work brings.
This means that your own organization likely is trying to make the tech stack conform to their own processes. Despite the fact that their processes were the product of old tech stacks and gaps/issues within those platforms.
There are several key assumptions that lots of development processes are fearful of which are notably lower within PowerApps specifically:
- source control (duh - your admins can see all source for everything you do and can even "block" deletion)
- version control (see above, plus versions are done automatically)
- QA/Testing (if you stay in the correct lane for PowerApps, you'll never need formal QA and can give this to the business - please post your hateful response below)
- dev/test/prod environments (ok - you might still do this - but a focused group can make due w/ only prod even for mission-critical applications - just don't do it out of habit)
Getting Traction Internally: Licensing
The #1 thing that most people will struggle with is licensing for their organization. For any platform, this will be an uphill battle to pry dollars out of hands w/o proof of value. However, if you're already on the Microsoft bandwagon then you'd be a sizeable idiot to not just lean into this platform and take advantage of all the greased ramps that Microsoft provides for adoption. I'm going to assume here that you're at least that far along in your journey. If not, then take a look at what low/no-code options exist within your current platform licensing.
However, sticking w/ Microsoft, from bypassing corporate firewalls and helping you ruin the days of your data compliance officers to free premium licenses being thrown out like candy at a parade, you'll find that if you let this beast into your organization, then Microsoft is hell-bent on pushing out into every corner of it. They are aggressive and they aren't taking no for an answer.
As a tiny cog in a large machine, it can be daunting for you as an individual actor. You might find yourself wanting to fight this kind of corporate dominance. Let me just say this, it is highly unlikely you will be successful in stopping outcomes that billions of dollars of organizational pressure desire.
Not saying you can't pull it off and still get paid, I'm just saying that when a whole lot of water is moving very fast, your best bet is to swim with it until you figure out if it is taking you where you want to go. If you discover it isn't, then it is much better to swim sideways to the current than against it.
So, if your organization has already invested in Microsoft, then investing in this capability is in your own interest even if your own leadership is expressing their doubts. In fact, see my original point at the top of this article that I'll restate here: If you deliver results, then it will be extremely difficult for anyone to challenge what you are doing.
I would warn you to try and avoid any form of premium licensing to the point where you have to pry that credit card out of your dying hand to charge it. Not that there isn't value in it, just that there is so much value in the base licensing that until you've exploited it you should avoid it at all costs.
Sure, the high-end apps and cognitive services functionality is flashy and exciting, but the core value of just creating basic data input and process applications is more than enough to get you the traction you need w/ near zero risk. But hey, if you want to stake your career on the hope that Microsoft has built out their image recognition to recognize a hotdog vs. somebody's naughty parts then go for it. You do you.
Strategic Applications
While I would recommend to anyone to start small and with applications that are close to home for their own team, you should immediately pivot to lightweight applications that are small, easy, but also visible beyond your area. Don't take the bait of jumping into replacing some massive Microsoft Access legacy application custom-built to run an entire department's processes. You can succeed at doing this, but you'll probably just wind up supporting that single application for the rest of your time at the organization and little else.
As a first-step application, I would suggest something that is highly process-oriented and touches on an array of departments.
Microsoft Forms
An easy starting point is a Microsoft Form that takes information from internal or external users, and then processes this via Power Automate to write the data into SharePoint, Excel, or somewhere else for a department to act on. See my post on this here.
There are literally hundreds of use-cases in most organizations for such processes. Lightweight form that can even be designed by non-technical staff, minor repeatable tech work for Power Automate, then depositing the data into a source the same business is comfortable using/accessing w/o your help.
- Flu shot verification forms
- Signup sheets for events
- Start of any workflow before you engage more technical resources
Digital Signatures and Contracts
Every organization has processes that require people to sign/execute agreements and retain them. Often times, this means building dynamic forms, merging data into existing formatted documents, and delivering those documents in a standardized form.
The most common pattern here is:
- PowerApp or Microsoft Form for data input
- HTML formatted base document
- SharePoint list to store proof of document execution
- Power Automate to convert HTML -> PDF
- Emailed and stored PDF for final signed document
A process for employees signing documents electronically and retaining such documents is central to most organizations. Lots of products/platforms sell entire solutions around this. If your organization has purchased licenses for Microsoft 365, then why not keep that money in-org instead of wasting it?
While this is a similar problem to the "Microsoft Access" trap above (in that you might get stuck doing this one thing forever inside the org), these kinds of processes are tied into Executive Leadership and are highly visible. Showing that you can build things quickly and securely will build trust w/ leaders who might otherwise never know you existed.
Building out a mechanism to digitally validate who is accessing the app and when they executed an agreement is everything your legal department wants to enforce whatever document has been "signed".
NOTE: Having the legal department owe you pays off in a variety of ways. 😁
Any small inter- or intra-departmental Process
The key word above is small. But that means small per the process, not necessarily in scope of the user base. In fact, large user base small apps can get you incredible traction.
One developer within our hospital system had built out an Excel sheet to track "hand washes" for staff. There's a whole workbook of the various situations where staff are supposed to wash their hands. He built it out so that it would track all of the events where a person did/didn't wash their hands and was intended for spot-surveys that would be occasionally performed inside the org.
After seeing what he'd built, I spent an hour building a mobile-friendly prototype to show him how to explain each hand-washing event at the time of capture and how to ensure it was tracked accurately. It was simple, self-explanatory, with easy simple Yes/No answers for every step along the chain. In a few clicks on a mobile phone, all information relating to the process of "handwashing" throughout the organization was communicated and the simple data captured. It was essentially just an 8 question survey w/ instructions at each step.
While this app took only an hour to put together, it impacted thousands of clinical staff throughout our organization every single day.
He eventually re-wrote to show off his own skills, extended out the data storage to retain details long term, and designed elaborate Power BI reports to show the impact on various initiatives and how they altered outcomes.
NOTE: inter-departmental are bigger impacts and always dropped balls, but can take notably more political dancing versus technical acumen to ultimately succeed. But finding a small process that hits lots of leaders is a huge win.
Anything Somebody Used Microsoft Excel For
I'm exaggerating (slightly), but if you spot any spreadsheet that a manager, Director, etc. is using to manage X (and if you aren't seeing that then visit an optometrist immediately), then ask a follow-up question of "how does that data get there?". You likely have found your first (or next) application.
Excel drives 90% of business decisions in Microsoft shops. And it is not the tool for the job of acquiring data to put into that same Excel sheet. To date, departments never really had a tool to do such a thing (unless they dove into Access). So if they're using Excel for decision-making, then figure out how to get them data into that same sheet.
Avoid Organizational Landmines Early
Until you're ready to lean on your credibility of prior successes, try not to get tied down in some "hot topic" that is a source for various departmental squabbles. As I mentioned above, inter-departmental applications are that largest wins you can gather, but stepping into the middle of a fight between departments isn't about the technology most times, it is about ownership.
Solving these problems requires highly successful and driven people (often with large egos) to accept that they don't have all of the answers. The best leaders will definitely get this if you show them, but people who lead have to drive almost all the time. Getting them to let go of the wheel is hard and abnormal. But the best ones will absolutely do it, once you pry their hands off of the wheel and stuff them in the trunk at least.
However, finding a small process that is a new inter-departmental process is your best first step (see the Digital Signatures and Contract design above). You'll build organizational clout for yourself that will let leaders see you differently and recognize that you also have answers sometimes. They'll be more comfortable relinquishing control to allow larger inter-departmental problems/projects to be tackled.
The worst thing you can do here is to pick a fight too soon when you don't have to (more on this below). Just pick up the scraps or small projects that others don't want or can't be bothered with. Start there and build your internal credentials before pushing for more strategic concepts.
However, don't just accept any old small project. There are plenty of departments who are just "problems" to work with. Organizationally this can be anywhere, however, it does tend to land on teams who are highly precise in ask but low in capability.
If I were to pick a specific high-risk kind of area, then I'd give the example of a marketing department that outsource every aspect of their creative work. They have an exceedingly precise ask of what they want, but they don't know how to do any part of it. You want your first customers to be people who are just happy their lawn got mowed. Not people who are out there w/ a ruler checking optimal heights per grass blade afterward.
While that is primarily organizationally specific for you personally, there is a near universal process you can use (in large organizations at least) that should also be a key source of projects (just not in the way they think of traditionally): IT Project Intake
I Said the Key Word Was Small
The "Project Intake" process for any IT team is about measuring impact/cost/value and assessing for prioritization within such departments. In fact, the best place for you to find projects are the ones that are rejected by such a process as "too small" for it.
This means there is a large amount of money on the table in the aggregate (lots of small projects), but the organizational inertia of the traditional IT/Development process wouldn't ever touch them. These are your bread & butter. If you only ever do these, you'll be a success. You'll also never have to challenge the more traditional culture/processes of IT because they mostly won't care about you.
Until somebody has a story in the news about something you've done perhaps. Or when your multi-billion dollar org wins a prize because of it. But if you do things correctly, you'll still slide in under the radar.
 |
| 2022 IU Health Mira Award winners (not pictured...me 👍) |
Just keep handling those "small" projects and stay focused on the impact/results over the notoriety. You'll not only make others in IT look good, you'll also make them pay attention to what you're doing. You'll get them questioning their assumptions about many things. But not in a way that overtly requires them to re-assess their own processes...yet.
However, the key per staying "small" (at least initially) is that this actually is the sweet spot for Low/No-code as an industry. You can do large apps, but the major benefit for these platforms is to move extremely quickly w/ minimal resources. Doing this for large applications certainly can work, but there are thousands of small applications that have zero solutions other than a spreadsheet.
In the end: why fight over if you can finish a large application w/ 30% less resources (after arguing with virtually every single person who does this today) when you can instead deliver a solution nobody else would have done and not have a single argument w/ anybody?
If you stay focused on getting organizational traction and getting results, then not getting into fights you don't have to keeps your limited resources aligned with the overall focus. What is that you ask foolishly? Results.
Under the Radar: Building toward change
People are quick to judge individuals who seek the spotlight as competitors. Someone who's after one of those top spots on the pyramid. The one thing we all have in common is that we're all just one single individual. If a group of people gang up on any one of us, then things won't go well (for us).
To get an organization to change direction, you need momentum that will fight against the existing organizational inertia. To build momentum, you need others to rally to your cause. To rally others to your cause you need to provide them with...results. The more voices you have clamoring for change, the more likely you'll have this momentum to force movement of the larger org.
The question will always be: when to stay hidden and when to step forward? That is something I can't easily answer for you. It is mainly that you have built enough broad goodwill across areas to show that none of this really is about you personally. This isn't self-promotion, this is an actual desire for real and substantive positive change.
If you step forward and become the face of change too soon, then you will lose credibility and stifle adoption while you are tied up in political fights with people who think this whole thing is about YOU. If you never step forward, you risk that others will step in front of your parade and turn it sideways into a brick wall.
 |
| As your new CIO I say: LET'S USE ORACLE CLOUD AUTONOMOUS DATABASES!!! |
Again, I can't answer this one for you or make your motives pure. However, if you're at least questioning if you, as an individual, are ready to stand up and take some level of personal credit for the momentum you're building, then your head is at least in the right place. Self-awareness of our own well-being is generally a good sign.
Just remember, while you might find this work ultimately benefits your own role within an organization, you agreed to leave that one to last. Let's try to hang on to that for as long as we can.
The Culture of Change
You might not work in IT. You might work in a contact center, a grocery, or in a warehouse. You may only loosely be associated w/ technology in that you are the person your boss always asks to help "fix their computer" when they have too many browser tabs open.
But in this scenario, this technology can only really impact your organization fully if you yourself fully adopt that culture of change. The recent Covid-19 pandemic should serve as a reminder of how even change where it is required is difficult for people to accept. Start with yourself before you try to change others.
People won't necessarily line up to change things even if things are terrible. Devil you know vs. devil you don't scenario. And far too many people are paranoid (with good reason) of anyone who says "this is better". Our present processes are built upon past successes/failures, and humans tend to remember failure/pain drastically more than we remember success. Therefore, you should never be surprised when people simply refuse to move out of the way of the train because they previously slipped on the gravel next to the tracks.
This reluctance to change is near universally true when it comes to Leaders. Leaders got to where they are because they understood how things were. If you're changing things...then they might not get to lead anymore.
That simple sentence contains a lot more truth in it that most people are comfortable with.
None of this makes people evil. Nor does it make them stupid. However, it can expose where people who are successful (and definitely people in leadership positions) may start to blur the lines between what is good for them personally vs. what is good for the organization. It is a universal curse that, as we all climb up in organizational leadership positions (and I am included in this statement), we all start to believe our own in-brain marketing department: If I get more power, then I can fix more things!
 |
| Muahahahahahaa! |
All I can tell you again is: nothing argues with results. Show them incredible and believable results, and it won't matter if your hot new diet plan is drinking urine. At a bare minimum, they'll sneak in a few glasses on the side w/o telling their friends. But they will be listening, which is what you want.
Leaders (and the rest of us) might not want to change, but they also want results. If change gets proven results, then they'll change regardless. So drive results and change will follow.
Of course, be prepared for an almost guaranteed conversation after you've succeeded. Sure you had results, but now we'd like YOU to change (and reduce your ability to deliver results) so that THEY don't have to.
Metrics and Reporting
I will say that most people focus on Power BI as their entry point into the Power Platform as a whole. It is not wrong nor is it unexpected that this is the starting point for the majority of people. It most certainly is when it comes to Leadership.
Power BI is heavily marketed toward data/analytics, where the entire market is geared toward building out ML/AI models and gaining insights from "big data". As well, lots of educational programs pushing people in this direction throughout the industry. Leadership across the board is tripping over themselves to see this data so the roles/hiring skews heavily in this direction.
However, this role has a well-worn path that will drive your to a very clear destination. Leaders like pretty reports and metrics on data they can show off to other leaders. Do this well and you will be noticed, coveted, and consulted to build reports for them until the end times. They will promote you within this path, but they will also create blocks to stop your escape.
To get out of this trap, you could probably go get your MBA and then turn that into a management position somewhere else or in a different department eventually.
Note: MBA training is primarily about training you to act in predictable ways so that investors can predict your next move.
I also want to point out that it doesn't make Leadership foolish to focus on metrics/reporting as that is the primary deliverable for their own performance. They don't generally "produce" anything except for the metrics from their own team. Most (and it definitely is most) leaders over-correct into the lane where they request reporting data vs. requesting applications that will ultimately deliver better metrics. It is, in essence, how they themselves are measured and how they interpret what "good looks like".
They are wrong, but that is how they are trained and it is the culture of Leadership in most organizations. The true standouts are the ones who focus on ways to improve the outputs that influence those metrics instead of focusing on the metrics as the starting point.
If your goal is pure self-interest, then I can't argue w/ those same results. Taking everything I've said above and then turning yourself into an MBA-having Power BI guru will get you a good distance down the road to wealth/power/leadership. You'll be able to push ahead based primarily upon the bias that: others have their MBA, and others are leaders, and others envy your results, and clearly you reporting on things others are doing is the same as you leading people, so now you're a leader, and hopefully you'll figure the rest out before they notice you haven't yet since all you deliver are reports with no insights beyond the data provided. Whew.
I myself want to at least refer you back to the EULA I mentioned at the start. You can use this entire platform to fast-track yourself w/ minimal labor here when compared to others. However, I want to remind you what you agreed to per the order of priorities:
- Humanity
- Employer
- Family
- Self
And while I'm cutting that list down notably to just land the point, I want to make it very clear that I view reporting on what is happening to be lower down the priority path than actually making things happen. It isn't that there is NO value in it, it is simply that the entire goal of reporting on what is happening is to hope that somebody will listen AND THEN will act to make things better.
I offer you this key thought:
Why not just jump the chain of events and go ahead and make things better today instead of waiting on somebody else to read a report, bring it to a committee, negotiate for funding, then eventually get around to asking you to do it?
Final Thoughts
Low/No-code is in a similar boat to solar panels, mixed-use zoning, etc. It challenges lots of embedded processes and interests. It is often difficult to even understand who you are fighting with. As well, even your most vocal opponents could potentially be allies if the problem is simply explained differently. Challenging ANY form of status quo will find resistance even if all agree that the status quo sucks.
The best paths for getting your own capability on such a platform to help your organization succeed is to pick projects that are small and unlikely to cause fights at all. And while inter-departmental projects always come w/ some kind of drama/fight over control, for small projects that get no love, almost everybody will lay down their weapons to rush to the table that you've just built out of thanks.
Finding projects and solutions that are small and impactful isn't all that hard if you're in the right room to hear them. Asking your IT intake teams of the kinds of projects that "shouldn't come through here" is in fact the easiest way in which you can create a model of the "perfect project" for you to start on. They don't want to touch it and the business partners often don't have readily available solutions for problems they definitely have.
I do want to close here w/ a warning per the entire Low/No-code movement. There is definitely a hook in this bait.
Microsoft (and Oracle, Amazon, Google, .etc...) wants our data so they can build AI/ML models based upon them. They want to sell those insights back to us in a variety of ways. We're going to be helping them understand our business better than the best leader ever will. There is significant long-term risk associated with that.
I will point out that the Data Analyst->MBA path I refer to above might seem like it is a fast-track, but once others have these insights: will the industry need you? I think the answer is a heavily caveated "yes", but the heyday of extra cash for paid insights will drop off significantly once they discover the golden goose of cost/value optimization using your formula that they now own.
However, while a dark future might one day arrive, there is no doubt that for this week, this quarter, this year, you can make a tremendous positive impact on your organization. Assuming your organization is aligned w/ making a positive impact on humanity then you and I have nothing to fight about here.
Unless you work in QA I guess.
Good luck and I look forward to your angry comment(s) below.
No comments:
Post a Comment
Because some d-bag is throwing 'bot posts at my blog I've turned on full Moderation. If your comment doesn't show up immediately then that's why.
DIAF Visualpath team