Since 1988, Grieg Pedersen has been developing exceptional software in Progress, achieving results many had said were impossible under the circumstances.  Manufacturing, retail or distribution, SyteLine or other Progress application, Pedersen Consulting is here to help.

Pedersen Consulting: extraordinary software, extraordinary service, extraordinary possibilities.

Grieg has accomplished this through agile practices including JAD sessions and staged deliverables, but most importantly by listening to his clients.  The importance of this cannot be overstated: the client is in charge.  You know where you want to go and what you want to do.  Grieg's job is to work with you to ensure that you get there and do that.

Grieg has led a wide variety of Progress projects, including:

• data warehousing ias far back as 1988;
• online shopping in 1991-95;
• custom SyteLine modules including:
  • a product configurator a clerk can maintain
  • integration of SyteLine with EB2
  • import of StackIT estimates into customer orders and job BOMs.

Any time a current process makes another business goal impossible it's time to re-engineer it or eliminate it entirely, and that's just what Grieg has done for companies like Retail Control Systems, Bennett Pump Company and TSSi MicroSage. 

At Gordon Food Service, Grieg used his unique perspective to fix software written by a large consulting agency.  That Progress V8 SmartObject had been declared "impossible to fix due to messaging bugs in Progress itself" by that agency.  It was Grieg's first exposure to SmartObjects, and he made it work exactly as expected - ahead of schedule and with a reduction in code size.

Pedersen Consulting practices agile development.  Requirements are gathered at the start of a project and scope is set.  Typically every two to four weeks on large-scale projects, code is delivered to to users.  It's not the complete package, but the users get their hands on something that's already useful and we work together to identify any mid-course corrections that may be needed and any requirements or business practices that were missed or have changed.  Without this iterative process, such deficiencies would be left for an unpleasant surprise at the end, when major redesigns would cause schedule slippage and significant cost overruns.  By delivering large software modules in pieces, we avoid that nasty surprise and instead bring such changes under the control of schedules and budgets.