Let's face it: in most development environments outside of the traditional corporate hierarchy, the PHP developer handling the highest-level aspects of development is essentially operating as a project manager, even when still doing actual PHP coding themselves. Occasionally even in a corporate situation, developers can suddenly find themselves thrust into a management role. In order to avoid having to bear the brunt of a failed project, there are few important things to consider that can put you ahead of the project management game.One of the most important things to do as a project manager is to manage the expectations of both the client and your team members. Frustratingly, a development project can succeed in its design specifications but still be perceived as a failure by the client simply because there were unrealistic expectations about how the features in the final product would operate. With that in mind, there are a number of things to outline at the beginning of any project: what resources will be required both during development and deployment, what the users actually require, and the full featureset that the client hopes to include. This especially applies if there are management levels above you who don't ever work as developers on the project, as they can easily lose sight of the original design specs - especially over the course of a long-term project. Take the time to be actively aware of how stakeholders feel about the project throughout each development phase, and you'll likely be able to head off most major problems before they get unmanageable.
One of the other incredibly useful decisions you can make is to choose to operate in an agile development framework. Traditionally-structured projects, termed 'waterfall' projects, have a clearly-defined development phase that only outputs a testable product near the end of the project development cycle, and this can seriously delay the detection of many problems that would have been easily corrected earlier on. The 'agile' development structure, however, presents a testable product every two weeks (or any other regular interval). This heads off questions of progress, as each new featureset is testable as it is developed, allowing for the identification of potential problems or misunderstandings much earlier in the development process, when they can be corrected or improved upon with relative ease.
The final consideration for the PHP-developer-turned-project-manager is the insidious problem of 'scope creep'. Scope creep is more or less what it says - the gradual addition of features until the original structure of the project has been lost, and you suddenly find yourself 6 weeks late and well over budget. It can come from a number of different vectors, but is often the result of a combination of agile development and upper management/client testing. It highlights the necessity of having the entirety of the featureset spelled out well in advance of the commencement of work, in the clearest possible terms.
Clients who like to operate in a 'hands-on' style often generate the most scope creep, but careful diplomacy can stop the situation in its tracks. While a certain amount of scope creep tends to be inevitable, and can actually be very beneficial to the client relationship, it's important to ensure that it doesn't get out of hand. With the careful application of these tips, you can prevent yourself from a managerial disaster, and focus on creating great PHP applications.
