IPM Global is very pleased to announce that we have passed the Microsoft technical platform certification for IPM Project Management â€“ â€śISV Tested and Certifiedâ€ť.Â But what does this really mean, many people ask â€“ it essentially means peace of mind for our Channel Partners and End Users.Â This technical test means that we have developed our application using best practice developmentÂ methods and that you can be confident that the product is solid and not â€śflakeyâ€ť.Â Microsoft have some very specific rules about how applications should interact with their platform.Â These rules mean that we just canâ€™t take shortcuts to get the job done, but instead we need to put in the hard yards to get it done properly so that the integrity of the platform (and therefore the application) are not compromised.
One of the most unusual aspects of our IPM development is the componentised approach provided by the Dynamics environment.Â Â We find we can develop sophisticated new functionality without risking our existing components because every document stands alone.Â This is one of the most difficult adjustments I have had to make as the architect of our product set.Â Each time we add a new feature the approach to QA is completely different to development work we were doing 10 years ago.Â In those days, a change in one part of the application could easily impact a number of different parts of the application.Â In the Microsoft Dynamics xRM environment, this is not the case.
The IPM Global team have just finished writing a new paper titled Practical Approach to Choosing a Construction Industry Integrated Solution. Today’s blog is the an excert from the paper and if you like it you can download it using the link below. Happy Reading!
The project game is quite a complex and risky one.Â Everything revolves around business processes, from approvals,to meeting follow-ups, risk management, change management (variation) control, the list goes on…….Â Typically, many of these processes are managed in one way or another, often externally via a spreadsheet, or an Outlook reminder, or quite frankly a piece of paper on the Project Managerâ€™s desk.Â And of course because every business, in fact every job, can be different, why should the software author be the one to determine what path a process should follow?