JoseB Blog

An IT Project Methodology describes how project work is identified, documented, assigned, tracked, tested, and deployed to end users.  At the start of my career, there was no true use of methodology. Requirements and tracking work was done in an ad hoc manner. A waterfall approach was used where all requirements, design, coding, testing, and deployment were done in their entirety one after the other.  This did not work well because by the time we got around to testing and the end users saw the app for the first time, often they would say, 'Hey this is not bad but really, it's not what we wanted, we wanted it like this instead, bla bla bla.' But by then the app was coded 100%, so it was too late to go back and do a rewrite because it would be too much work.  In the end, we would patch the app with band aids to give end users something resembling what they really wanted.  Later in my career, I was exposed to several methodologies including Method1, RUP, and eXtreme/Agile. In

Here are the seven disciplines that you must get right, or the project will fail. This means if you get just one of these wrong but the rest right, the project will still fail. It's all or nothing. It's very unforgiving. It's like a chain, if one link fails, the whole chain fails. Methodology - how the project work is managed Requirements - what the app will do Architecture and Design - the foundational structure of the app User Interface - what end users see and interact with Coding - self explanatory Testing - self explanatory Environments and Deployment - how the app moves from development to production We will dive deeper into all of these in later articles, but for now the question becomes, "How do we guarantee that we succeed in each discipline?" The answer is that there must be one person on the team that is responsible and accountable for making sure that quality is maintained in each discipline.   We will get into the different roles of the project team m

I graduated from college in 1978 as a Computer Science major and worked in IT for forty-one years, retiring in 2019. In my career I programmed apps on everything from standalone mainframes to internet connected phones. In 2001, I was somewhat reluctantly promoted to IT Management at a large company employing hundreds in the IT Department and that is where all my technical project management experience comes from. There, I was exposed to many different IT methodologies, and thru trial and error, I arrived at a development approach that worked well. It borrowed mostly from agile / extreme methodologies, but also borrowed some of the useful RUP artifacts such as the Use Case and the UML Class and Sequence diagrams.  I managed a team of custom app developers, and it took years of hard knocks to learn what worked and what didn't, but in the end the driving force was always to BE PRACTICAL and only do those things that provided value in terms of making the project succeed, so agility was