During the kick-off of any new software project, a senior stakeholder will often produce a slide that explains why a high percentage of software projects fail. The intention is often to explain how the soon to be kicked off project will not fail. If you search for “Why software projects fail?”, you will find a variety of failure reasons, such as general people issues, time, lack of testing, unclear requirements, scope creep, inadequate communication, staff retention, poor risk management and more. Continue reading “Five ways to make Power Apps and Low Code Projects succeed”
Just before I started my working career, I completed a social sciences degree in Communication Studies. For the most part, this was a non-technical IT degree. It was one which made me think deeply about the day to day encounters I have with other people, written, verbal and more. With the job market not being awash with social science jobs at the time, and having hacked around a lot with BBC Basic on an old BBC Micro and Acorn Archimedes in my formative years, I felt a pining for programming again, so I forged a career in the IT industry. I’ve been here ever since. Continue reading “Five ways to become a Software Engineering Multiplier”
I normally do my weekly grocery shopping online, however since the Coronavirus lockdown and because of the shortage of home delivery slots, I have the first world problem of visiting the supermarket again in person! After returning from a shopping trip this week, I saw a meme on twitter which reminded me of the dilemma most supermarket shoppers face after unpacking their shopping into their car – namely looking at the empty shopping trolley and wondering where to return it to. To quote the tweet :
I really enjoy the early phases of new greenfield Microsoft Business Applications projects. It might be delivering a fixed scope project with expected outputs already defined. It might be formulating and documenting new requirements for a truly agile project. Fundamentally however, it’s about getting into the minds of business users, perhaps building some SFDs and mapping the technology to participants, perhaps unknown, wants and needs. Continue reading “Five Tips for Running Remote Discovery Workshops during a Pandemic”
A few months ago I met an old colleague – let’s call him Ben, and we got talking. He is an experienced Microsoft developer now working on a greenfield Dynamics 365 project. He’d picked Dynamics up quickly after a few months training and upskilling himself, and had a good grasp of the platforms functionality and extensibility techniques. Our conversation went something like this :
Him : I’m working on a potential 200 seat project for <financial organisation> for a Sales Process. I’m going to automatically create a lead when my custom entity changes status and allocate it to the correct sales manager.
Me : Are the sales guys using Leads at the minute or how are they tracking leads outside of D365 – spreadsheets / access / onenote?
Him : Not sure, but that’s what’s going to happen – the Business Analysts have already modelled it in our new process flow diagrams. Once the lead is qualified, we need a trigger to create a case against the related account so another team can track the lead.
Me : What is the purpose of the case? Are you sure you need to use the case entity here?
Him : It’s mainly just for tracking purposes, but the new process says we might need the ability to merge cases sometime in the future. I’ve nailed the security model for cases and leads based on our to-be business units. Dynamics is great for that.
Me : Ok,it’s good you are thinking about security. Have you considered the licences each of these users might need alongside the security rules?
Him : No, that’s not my department, my manager deals with that, I just have to design and build the solution before year end. Licences are in next year’s budget. The project needs to save the company £200k per year by year two.
Me : Hmm. Let’s discuss this in more detail.
The conversation with Ben got me thinking about my approach to initiating projects and how my approach to development and design has evolved over the years across a variety of software projects. Methodologies included :
There’s a lot of talk about software delivery methodologies these days. To those not constantly reading the latest 400+ page textbooks on methodologies, it can be quite hard to keep up.
Agile methodologies such as Scrum can be great, but to work optimally they require a fair amount of education for all stakeholders involved, which is not always practical. Waterfall is considered by many as old hat, but lots of successful projects are still delivered this way. Hybrid methodologies can also work and can work practically and commercially. What is more important, across whatever methodology you use, are the techniques you use as part of these methodologies to define solutions and deliver real business outcomes.
There is a technique that I like to use which is ideally suited to Dynamics 365 and the Power Platform. It’s a great technique because:
- It helps you gather real requirements aligned to the technology. We shouldn’t pretend to understand what someone else is imagining about a technology they have never seen before and try to make it fit.
- It starts you thinking about the end-game very early in the process.
- It helps you learn new technologies and capabilities as they are released.
- By virtue of this techniques name, you are setting the bar quite low, so risk of embarrassing yourself is minimal (although conversely, partial failure here may be a very good thing).
- It can provide valuable insight into estimates for future tasks.
It’s called the Shitty First Draft, hereby referred as an SFD.